What is the maintainability concept? And why apply it?

The maintainability concept, absolutely not to be renounced when it comes to programming, has to find an important space even in the creation of a traditional website. When you find yourself ( and sooner or later you will get there) having to retouch a website you have finished six months ago, could result into a real nightmare if we haven’t correctly projected its maintainability.

As a consequence we might spend hours searching for a file or trying to understand why we wrote that line or where is that the class of the style sheet acts.

It’s worth taking the time to observe some basic rules starting exactly with something which often is left to chance: the files.

Why should I define namespaces for the files?

This term – stolen from programming- simply means attributing a uniform standard to the names we use. A wrong example could be this one:

loginArea.html

customer_area.html

User-profile.html

It’s better to choose a model and apply it to all the files.

login_area.html

customer_area.html

user_profile.html

Always talking about files and namespaces, think about how are the files going to be displayed when you open a folder a and make sure they are well-arranged in the easiest way for you , I will give an example immediately:

delete_user.php

add_user.php

modify_user.php

In my logic (I’m underlining my since maintainability is subjective, everyone applies his/her own personal logic) I prefer to assign the names like this:

user_delete.php

user_add.php

user_modify.php

So that when I open the folder which will contain other three hundred files (shown in alphabetic order), they are grouped by “topics”. As I said it is a matter of preference; in fact somebody might argue that the first model is better if seen from this perspective:

add_user.php

add_page.php

add_section.php

That’s true. What’s important is establishing a logical criterion and keep it in order to make the content of the folders as homogeneous as possible. Obviously we could apply the same concept also for the images or for the files to be downloaded. For example, we shouldn’t find a situation like this in the download folder:

catalogue_january_2010.pdf

Catalogue_02_10.pdf

catalogue-mar-2010.pdf

The consequence, as in other cases, is that you will have trouble tracing back the files. Always think that the folder could become huge with the passing of time.

Why should I worry about applying a correct indentation?

A well-indented code is very legible and easily comprehensible:

<div>
    <ul>
        <li>element 1</li>
        <li>element 2</li>
    </ul>
</div>

While such messes:

<div>
<ul><li>element  1</li><li>element 2</li>
</ul>
</div>

in a maybe long and complex page make you lose time during the update/maintenance phase.

Why should I lose time commenting the code?

Inserting comments in the code that we are developing, whether it is programming or simple markup (XHTML/CSS), is an action which is often neglected. Useless to say, due to that, we pay the consequences in the updating phase.

Let’s impose ourselves on commenting the code. I know, when we are working on something everything looks clear. But after a week already we might encounter difficulties in spotting the points on which to take action. Let’s comment then the beginning and the end of the various sections. Let’s concentrate on particular passages, on that fragment of code which we have put to resolve the compatibility with Netscape 2.4.3.

#container{
    margin: 0 auto;
    width: 960px;
}

/* resolution of compatibility with  old versions of IE*/
.ie{
    text-align: center;
}

.content{
    text-align: left;
}

Organizing the style sheet

While developing modern layouts, we often encounter complex style sheets; It is thus indispensable arranging them in a very orderly manner. There are two schools of thought regarding this: alphabetic order or arrangement by section (header, navigation, etc). As you already had the chance to see, there is no wrong or right method: important is that you are able to see through the logic behind and that the latter is always respected.

Besides, even in the style sheets the comments can help us to be more clear or speed up a future intervention on the layout styles.


Besides we foresee a final optimization. If we look carefully at a style sheet, we would surely find redundant lines which we might be able to eliminate, or a missing exploitation of CSS heredity characteristics. Let’s take a random example:

body{
    font: 14px arial;
}

a:link{
    color: green;
    text-decoration: none;
    font: 14px arial;
}

a:visited{
    color: green;
    text-decoration: none;
    font: 14px arial;
}

a:hover{
    color: gray;
    font: 14px arial;
    text-decoration:  none;
}

.link_2 a:link{
    color: blue;
    font: 14px arial;
    text-decoration:  none;
}

.link_2 a:visited{
    color: blue;
    font: 14px arial;
    text-decoration:  none;
}

.link_2 a:hover{
    color: gray;
    font: 14px arial;
    text-decoration:  none;
}

This code is very redundant and doesn’t use CSS characteristics. We can make it compatible in this way:

body{
    font: 14px arial;
}

a:link, a:visited{
    color: green;
    text-decoration: none;
}

.link_2  a:link, .link_2 a:visited{
    color: blue;
}

a:hover,  .link_2 a:hover{
    color: gray;
}

Another thing I consider a hassle (but as always it’s personal) is subdividing the style sheet in various files.

The navigation: a fundamental element which is to be studied in maintainability

In case of updates/adding of contents, a problem which occurs often is that of navigation.

We had created a great horizontal navigation, which was foreseen for six items at maximum. And now dozens of new content arrive subdivided in four new sections. Maybe it is that client who when contacted you firstplace said to you: “Yeah, I need a website with two or three pages. You know, the introduction, the contacts, and in the third I don’t know yet what to put. Don’t worry”. And now we reached 4TB of contents. It has happened to everybody at least once. Thus, from the moment we know that a website is destined to grow (even when the client has told us the contrary), when possible we try to project an extendable and maintainable navigation.

Let’s imagine the possible under-menus, we think of how it could grow or how it could be modified and extended without missing a week. It is something fundamental, we separate it from the content (please not by means of frames). Two lines of PHP are enough, and their use is relatively simple, even though programming is not your cup of tea.

<?php
    include  "navigation.html";
?>

In this article you can find a detailed explanation of this procedure.

Besides navigation, we obviously have to imagine even the possible content growth and as a consequence how to organize it in an orderly manner.

If the website is not managed with a CMS, we foresee sections and eventually undersections with relative folders and, as said previously, the application of namespace to the files will result very helpful.

Using the conventions and the semantic approach

I am a programmer, environment in which conventions can save you. The column of a database which contains the primary key, is conventionally called “id”. I can name it as I wish, I could call it “Ezekiel“, but why should I? That would just bring confusion.

Similarly, for example, the div used for containing the various elements of a document, as a convention is called “container” or “wrapper“, thus we use conventional names, why should we invent others?

Always talking about names we deal with the semantic approach in which an example is worth a thousand words:
Let’s consider this layout scheme

Seems like going well. But what would happen if, in mid-stream, we decided that the best setting was this?

We’d find ourselves in the unpleasant situation of having to modify the names used in the style sheet. With a semantic approach instead we wouldn’t be having any problem.

Using the CMS

When the contents is too much and/or updates are frequent, being based on a CMS is obligatory. The use of one of these softwares resolves in a single hit only the major part of maintainability problems we have seen in this article. But obviously even in this case, besides choosing the right CMS for our needs, we have anyway to pay attention to maintainability in the first phase of setting.

Conclusion

Most probably everyone of us has had the chance to encounter in more than one occasion problems related to maintainability; what was exposed in this article surely doesn’t constitute big news but the issues dealt with might anyway be useful to make order during the projection phase of your next website.

And you, how many times have you cursed yourself for not keeping track of maintainability in any website of yours?

Master per Web Designer Freelance
In tutti questi anni abbiamo ricevuto centinaia di richieste di approfondimento sulle numerose tematiche del web design vissuto da freelance. Le abbiamo affrontate volta per volta. Ma ci siamo resi conto che era necessario fare qualcosa di più. Ecco perché è nato One Year Together, un vero e proprio master per web designer freelance che apre finalmente le porte al mondo del lavoro.
Scopri One Year Together »
[pdf]Scarica articolo in PDF[/pdf]
Tags: ,

The Author

Maurizio is married to the triad PHP - MySql - Apache and, not enough, he has a lover called jQuery. He has a blog where he tries to describe in detail all of "his lovers". His real specialty is the realization of large business application, altough he never refuses the commitment of a website.

Author's web site | Other articles written by

Related Posts

You may be interested in the following articles:

4 comments

Trackback e pingback

  1. Tweets that mention What is the maintainability concept? And why apply it? | Your Inspiration Web -- Topsy.com
    [...] This post was mentioned on Twitter by V. Tavares (E-Goi). V. Tavares (E-Goi) said: What is the maintainability concept? …

Leave a Reply

Current day month ye@r *