Is progressive improvement so expensive?

The previous article dealt with the theory and practice of progressive enhancement. In this article, we will move from ideology to axiology and consider the financial and economic feasibility of applying progressive improvement.

Some comments on the previous article expressed the opinion that it was not worth using a progressive improvement in actual development. The reasons were reduced to the excessive cost of living: “In order to create a website in accordance with this approach, you need to spend too much time, and this is too expensive and neither the customer (for that kind of money) nor the performer needs it.”

Since the whole question, as usual, in time and cost, in this article we will consider the "progressive improvement vs ordinary development" in terms of additional time costs. As in the previous article, we will do this in stages.

Stage "Old-good-HTML"

At this stage, the coder creates logical and semantically correct HTML markup without using CSS. No additional time costs at this stage arise. Naturally, it is more convenient for some typesetters to create HTML-code and at the same time throw styles. Progressive improvement does not forbid this: please write and styles, but first pay close attention to the markup.
')
There is a small but important detail: you need to think about the correct order of the code so that the page without styles looks logical. For example: if it is important that the phone is at the top of the page, then in the code it should be at the beginning, not at the end. After all, sometimes the phone in the layout in the right column is pushed into the html-code block located near the end of the file. Without styles such a phone will be far, far away.

CSS Stage

Important note: progressive enhancement has nothing to do with the layout for Internet Explorer 6 . Layout for IE6 - which not only does not support the standards, but supports them incorrectly - is a separate task, which for many performers is called - “layout for IE6” and is additionally evaluated. Thus, IE6 support adds extra cost for any approach. If the client wants to pay for it - please, and if not, then he does not need to vtyuhivat it.

For those who insist on the support of IE6, I will give an analog with encodings. Previously created several versions of the site, sharpened for different encodings, for example, KOI8-R and Win-1251. They don’t do that now, though, if you wish, you can dig out and run a Very Old Computer with Very Old Windows. So maybe it's time to forget IE6 like a bad dream?

As for other old browsers that correctly support CSS2, the site will look decent in them. Under the old Firefox 3 back in 2008 it was easy and pleasant to type out.

So, progressive improvement does not introduce additional time costs in the second stage. Indeed, the task of creating a page grid and a simple design using CSS2 features for an experienced layout designer is trivial, whatever approach he takes.

CSS3 stage

Important note: progressive enhancement does not require the site to display equally well in all browsers. Quite the contrary - the site should be displayed in the browser adequately to its capabilities. The browser does not know how to draw the corners - it's okay, there will be square corners. Progressive improvement is very pragmatic in this approach.

Agree, this approach is very practical. We have already taken care of neatly displaying the interface in the previous step. And at this stage, we gradually make the interface more beautiful for those browsers that support new properties. With minimal effort and time . This means that you can forget about cutting out a bunch of .png files for corners and shadows, about a bunch of nested divs and tons of unnecessary markup.

All this leads to a huge time savings. And as a bonus, the coder begins to enjoy work, because he gets rid of the routine and at the same time gets room for creativity and experimentation. After all, the saved time can be spent on other projects, or you can experiment with the latest properties on the current project, adding wow features for users of new browsers.

To summarize: in the third stage, progressive improvement provides significant savings in developer time.

Javascript stage

This stage is the most controversial and the most interesting, therefore we will dwell on it in more detail and analyze a few practical examples.

At first, a small caveat: we will not consider sites whose operation without JavaScript (JS) is in principle impossible or loses all meaning, for example: Yandex.Maps, Htmlacademy, various online IDEs, and so on.

In general, it can be said that with the right approach, there is an additional investment of time at this stage, but they are small. Basically, they come down to the complexity of script initialization. Sometimes additional costs can be significant, as there is a complication not only on the client, but also on the server.

The various situations arising at this stage are best analyzed using practical examples.

Example 1. Form "Order a call"

Task: “On each page of the site there is a link“ Order a call ”, when clicked, a callback form with an overlay pops up”.

The task was solved in accordance with the progressive improvement as follows:

1. The HTML code of the form is inside the page code.
2. With CSS, the simplest form appearance effect is made: the form is initially hidden, only the “callback” link is visible. When you hover over the link, an absolutely positioned form appears:
   
   
   
3. With the help of JS, additional classes are added to the form, with the help of which the display logic is changed. Also the behavior of the form, the positioning mechanism will be improved, an overlay is added.

What did we get in the end? The form exists in the body of the page and is always available in “bare-HTML-mode”. In the presence of CSS, the form is hidden, does not break the grid, and is able to be displayed when hovering. Realization of this behavior on pure CSS has its drawbacks, but the form remains available . Using JS, the display and behavior of the form is reduced to the desired ideal.

Additional time costs in this example are minimal. To the necessary JS-logic, you need to additionally add additional classes to the form and add to the HTML code for the overlay. This is the very complexity of the initialization of the script.

Example 2. Hotel search form

This example is described in a post about Graceful Degradation . The task was to make the hotel search form work without JS. For this, we had to refine not only the client part, but also complicate the server part. The server has learned to distinguish requests for loading locations from search requests.

In this example, the additional time costs are already more substantial. In total, they amounted to approximately a working day. Are they justified? Note two points:

1. The importance of form. Work with the site almost always begins with finding a hotel.
2. The importance of filtering by location: hotels are often searched for in a particular city or even in a specific area.

Thus, the search form and filtering by location are related to the basic, necessary functionality. So, in this case, the additional costs were justified.

Example 3. Pizza Constructor

The challenge is to make a website where you can order a pizza. Moreover, pizza can be ordered both in the “original configuration” and in the modified one: choose the dough, change the sauce, add additives. Finalization of pizza is made in a special constructor.

The task was solved in accordance with the progressive improvement as follows:

1. When you click on the link “Order Online”, the pizza is added to the basket in its original version.
2. If JS works, then when you click on the link, a designer appears in which you can select the dough, sauce, additives, after which you can add the already finished pizza to the basket. Here are examples of the interface:

With this solution, as you noticed, the finalization of the pizza with the help of the constructor is possible only when JS is running. To make the same designer working without JS will be long enough and expensive. Is it worth it? In this case, most likely, it is not worth it, because:

1. The basic functionality for such sites is the ability to put in the basket your favorite pizza. After placing the order, the customer is called back by the operator, who specifies the details of the order, delivery, etc. That is, the client can always “tune” his pizza with the help of an operator.
2. JS is disabled for a small percentage of users, and this functionality will be quite expensive and will delay the deadlines (and other typical arguments against progressive improvement).

As you can see, in the context of progressive improvement, you can refuse to implement additional functionality on “pure HTML”, which will save both time and money.

But! If suddenly the customer finds the designer critical and wants it to work without JS? This can always be done for an extra charge. The key point is not to include the cost of such modifications in the original estimate.

Conclusion by example: progressive improvement should be applied correctly, without fanaticism. If there are serious additional costs, then let them appear at the conscious will of the client, and not by the developer’s folly . Or, to put it simply, there is no need to entice these additional costs to the client just because “it seems to be correct in terms of progressive improvement”.

To summarize: in the fourth stage, progressive improvement in most cases leads to insignificant additional time costs. In some cases, costs are substantial. Once again, progressive improvement requires that only basic functionality is always available . And to implement the basic functionality without JS in most cases is not so expensive.

Total

Additional time costs when applying progressive improvement at each stage:

1. HTML stage - absent;
2. CSS stage - absent;
3. CSS3 stage - saving time;
4. JS stage - are present, but insignificant.

Minor costs at the scripting stage are more than offset by time savings at the layout stage. As a result, we get time savings, not additional costs.

However, for progressive improvement to work efficiently, two conditions are necessary:

1. High qualification and experience of developers. It is impossible to do everything from the first time quickly and efficiently. First you need practice. But after all, it was also painful to learn how to use OOP in PHP.
2. Both the customer and the developer must come to terms with the fact that the site in some browsers, especially old ones, will look “worse” (and even collapse in IE6).

Conclusion: progressive improvement is a good pragmatic approach that allows you to develop interfaces faster and better. And progressive improvement has nothing to do with perfectionism.

In conclusion about the sad

Why do many studios believe that progressive improvement makes development too long and too expensive, and therefore unnecessary for customers? In most cases this is due to the lack of qualified developers who do not understand the essence of the approach and do not know how to use it.

The problem with personnel in the market is acute. It is hard to find a good programmer, but a good layout designer is a very rare fish. There is no place to take them, because even in the leading IT universities of the country they do not prepare good layout designers, and they do not set themselves such a goal. It is hoped that the new GEF with their competence-based approach and market orientation will help improve the situation. For now, it remains to grow good specialists by ourselves.