Web & application development

A brochure site publishes information meant to be read: it changes only when someone decides to change it. A web application moves work forward: it holds accounts, rights, data that changes state as it is used, and rules that decide what is permitted. The distinguishing criterion is neither the number of pages nor the appearance, but the presence of state that evolves. It is that criterion which governs how to check the result before going live, what hosting is needed, and what maintenance load to expect afterwards.

The question is settled by looking at what is genuinely distinctive in your activity. If the need is ordinary — publishing, selling in a conventional way, taking appointments — a configured product does the job and its upkeep is carried by others. Bespoke development is justified when a business rule, a sequence or a constraint specific to the organisation cannot be expressed in an existing product, or when adopting one would mean distorting what works. The middle path is frequent and often the best: an existing base, completed by development limited to the precise point where the organisation differs from the others.

None of it goes without saying, and it is settled in writing before starting. Three distinct items are at stake. The domain name, which must be registered in the company’s name and not the supplier’s. The source code, where you need to know whether it is assigned outright, licensed for use, or made of open components subject to their own terms. And the data, which must be recoverable in full in a format usable outside the tool. To those three are added the credentials: hosting, database, third-party services, deployment procedure. Holding the code without the credentials does not make you autonomous.

Acceptance testing is the verification, by the person who ordered the work, that what is delivered does what was asked. It differs from the developer’s tests, which verify that the program does what its author believes he wrote. It is carried out by people from the trade, on an environment separate from production, with realistic data and scenarios written in advance. What you look for is what breaks rather than what works: empty fields, over-long text, unusual characters, simultaneous actions, the browser’s back button. It concludes with a written decision and with the sorting of what is a fix from what is a change.

It covers three activities better kept distinct. Corrective work deals with the defects observed. Evolution adds what use has revealed. Keeping the thing running consists in updating the components the site depends on when a vulnerability is published, following the versions of the language and the system, renewing certificates, checking that backups restore and that third-party services have not changed their interfaces. It is that third activity which answers the question: software that is not touched does not stay stable, because everything it rests on carries on evolving without it.

Perceived slowness has cumulative causes, and it helps to know which one dominates before acting. Images that have not been resized and are served in an unsuitable format are often the cause. Next comes the amount of code loaded and executed before the page becomes usable, often inflated by scripts added over time without anyone removing any. Then server response time, tied to hosting and to the queries made to the database. Finally the choice of computing pages in advance, on demand, or in the browser. These causes can be measured, and the measurement is taken on an ordinary device and connection, not on the developer’s machine.

Accessibility is the property of a site of being usable by people whose capacities, tools or conditions of use differ from what is imagined by default. In practice: a correct page structure, so that assistive technologies announce what the elements are; full operability by keyboard; a label associated with every field; sufficient contrast; no information carried by colour alone; the active element always visible. It serves far beyond situations of disability, because a poor connection, a screen in bright sunlight or one occupied hand create the same needs. It is designed in from the start: taken up at the end, it forces components to be rebuilt.

A properly designed site adapts to small screens, updates itself without any action from the user, opens from a plain link and depends on no app store. That covers most everyday needs. An installed application is justified when you have to work without a network, reach device features the browser does not expose or exposes poorly, send notifications reliably, or support daily and intensive use. Its real cost is not building it but living with it: separate systems to follow, releases subject to approval, older versions that stay installed on users’ devices. What has to be settled is the expected use, not apparent modernity.

A programming interface is a set of addresses through which one program asks something of another and receives an answer in an agreed format. In a web project it separates the visible interface from the rules and the data: the screen asks, the server decides and answers. That separation has three practical effects. The interface can be rebuilt without touching the rules. Another tool — an internal application, a mobile app, a partner — can be fed with the same data. And third-party services, payment, mapping, message sending, are integrated through the same mechanism, with the dependency that implies: their terms, their availability and their changes become yours.

A site already known to search engines has accumulated something invisible: indexed addresses and links pointing at them. A reconstruction that changes the addresses without redirecting them loses that, and restoring it takes more effort than preserving it would have. The precaution consists in taking an inventory of existing addresses before starting, deciding for each one the address that succeeds it, and putting permanent redirections in place at the moment of the switch. Two checks complete the operation: removing the instructions that prevented indexing during construction, and confirming that the important pages remain reachable. Content remains the deciding factor: a rebuild that impoverishes it degrades the outcome whatever the redirections.