Re-visiting this page in 2023, I find myself troubled by my use of “layout”: the word is at best ambiguous, at worst outright misleading.
However, the same applies to e.g. “presentation”, “display”, and “rendering”, each of which fits better or worse depending on the exact context. Moreover, this text has had a name including the word “layout” since 2010 (?), and sufficiently many years have passed that a change might do more harm than good.
Correspondingly, I stick with “layout”, for now, and hope that my meaning will be clear anyway.
(Minor other terminology issues can exist, e.g. whether “content” or “contents” is the better choice in any give sentence.)
It is almost always a good idea to separate the concerns of content and layout; be it during own thoughts, development of software components, writing of documents (easier said than done, I admit, for those stuck with MS Word), or any other area. Doing so puts the focus where it belongs, avoids wasting time with appearances before it is actually needed (if at all), leads to fewer errors and better maintainability through a cleaner division, allows better opportunities to delegate work to other parties and to let specialists work on their specialties, and so on.
In fact, the realization that this split is important is a very good indicator of ability in a software developer: Those who do not have it are rarely (never?) worth their money; those who do usually are. (But some reservations have to be made for mere lip-service.)
Unfortunately, far too few developers have this realization—and when we move to other groups, including business graduates, it is typically a rare exception.
This text is largely written from a software-developer and/or “own work” perspective. From a software and/or “corporate” perspective, the likes of business graduates are sometimes more important obstacles to good separation, e.g. when a product manager makes feature decisions that indirectly affect the presence/absence of separation in the software under development (be it on the implementation side or the user side).
Below I discuss some examples of how a separation, or lack thereof, affects work. A separate article on WYSIWYG contains a more detailed comparison of LaTeX and MS Word in this regard.
In many works on writing, e.g. guides on how to write a dissertation, a sizable portion of the text is dedicated to discussing margins, spacing, how to write a correct reference, how a mathematical formula should look, and similar issues that are of little relevance to the actual work at hand. In contrast, LaTeX (and some other tools from the academic computer-world) takes the approach of providing logical markup, in which the user merely provides the contents (including indications of type of content and the structure of the document). The user writes his paragraphs, chapter headings, lists, tables, formulae, whatnot, and LaTeX automatically renders the content in a way thought out by experts. Even hyphenation is handled automatically. Should changes be needed, the specification of the layout is altered in one place, and the change is effective everywhere in the document. In particular, various scientific journals have different pre-packaged specifications (corresponding to the layout they require for publishing) that can often be applied to a LaTeX document through a simple one-line include—no additional work is needed to make the document conform.
This has large advantages for the authors: They can focus on the actual contents of the document. Clarity and originality of thought, correctness and readability of language, and so on, have the main seat—not sifting through a text to see that all margins are in the exact right place or that other semi-arbitrary and locally varying typographic conventions are followed.
The reason for these specifications are probably originally to be found in the use of typed-on-paper documents for academic essays, master’s and doctoral theses, etc., not intended for large scale publishing. Even as late as the early 1980s, computers were comparatively rare even in the academic field, and professional type-setting capabilities only really became available with TeX (for which LaTeX is basically a set of macros) at roughly this time. Further, unfortunately, TeX and LaTeX have rarely been adopted outside the hard sciences—possibly, because writers in the soft sciences very often can get by with the characters present on the keyboard of a typewriter, or because computers were rarer in these fields. (Notably, the first uses of computers where in areas such as number crunching—where mathematicians have a larger interest that students of literature.)
Writing in 2023, having seen so much more of e.g. social scientists (or, depressingly often, social “scientists”) than at the time of the original writing, I suspect that an equal explanation is lack of brain power, be it manifested in an inability to handle e.g. LaTeX or in an inability to understand that the initial effort of using LaTeX instead of MS Word (or, earlier, a typewriter) will pay off for even a single master’s/doctoral thesis or even just a few scientific articles.
If we now look at HTML, it started in a similar manner: The author enters his text, headings, whatnot, in a corresponding markup language (the “ML” part of HTML), and the rendering is done by whatever client/browser the reader uses to access the document. Originally, the rendering and capabilities of HTML were very close to plain text: The possibility of linking was there, but the rendering was limited by the text terminals originally used. As GUI browsers became prevalent around 1993–1994 and, in the following years, commercial companies flooded the Internet, the development of HTML took a very unfortunate turn:
What should have happened was a development to something resembling LaTeX (in its capabilities, not necessarily syntax; and taking the different field of use into account). Someone providing a website would have written his texts in a fix markup, put his navigational structure into a similar definition, possibly given some advisory layout instructions (e.g. a preferred background color), and similar. This would then have been rendered by the user’s browser according to his preferences and to what the browser makers considered usable.
Some modern CMS’s, blogging systems, and similar have some capabilities in this direction, but with the major drawback that the reader’s control is limited, and that the rendering of menus and other usability features are determined by the CMS instead of the browser. Ditto various color choices, font choices, whatnot. If customization can be made, e.g. through “skinning”, it is usually done on the wrong end. For instance, Wordpress allows considerable layout customization by the blog owner, while the actual reader has to live with whatever is provided—the opposite of what should be.
The result would have been a high degree of user-friendliness, a consistent look and navigation (based on browser, respectively user preference), no nasty surprises, no need to have a specific browser to view a specific site, etc. With a bit of luck, although this might be over-optimistic, the average website might actually have had contents worth reading...
What did happen: Layout was given priority, executives and web-designers obsessed over unimportant details, websites often required specific browsers or screen resolutions, every website had its own navigational solution, etc. New functionality was introduced in an incompatible manner by various browser makers (e.g. JavaScript, Active-X), or third parties (Java, Flash). All in all, a splendid example of the proverb “Too many cooks spoil the broth.”...
Notably, as of 2010, HTML it self does not contain something so basic as markup tags for the definition of menus; and many other functions that could today be an integrated and well-thought-through part of HTML are provided only by third-party solutions (e.g. RichFaces) or company-internal (and usually low-quality) solutions.
With the introduction of HTML 5, still in planning when this page was originally written, and its greater focus on the “semantic web”, some few steps have been taken to rectify the faults discussed above.
I even had some hope that later versions of HTML could land us solidly on the
right road, even be it with a delay of several decades and an enormous
and unnecessary waste in those decades. Unfortunately, modern web design
has, again, gone down the wrong road and seems to consist mostly of deeply
nested div tags (generic and with no semantic implications), which
are given their look, position, whatnot through CSS.
The obvious area of application for a software developer is GUI development. Rather than re-hash what has already been repeatedly written on this topic, I recommend the reader to brush up on the motivations of e.g. MVCw or Three-tier_architecturew.
In brief, however, consider the amount of work needed to replace one GUI with another or to port to a different platform/framework, the ease of maintenance, the level of abstraction and the independence of the back-end from the front-end, and similar.
Separation of content and layout is a special case of the more general principle of separation of concerns. Importantly, however, not separating content and layout is almost always wrong; not separating other concerns is in many cases harmless (or does only limited harm). In some cases, it can even be beneficial, e.g. for sufficiently small applications. (With the major reservation that what is small will not always remain small: The assumption that a certain “easy” solution will be acceptable because a program is small, intended to be used once and then thrown away, or similar, has come back to bite many a developer—often on repeated occasions. Err on the side of too much separation even privately; do so even more in the office.)
Further, only rarely will the general public be exposed to other special cases of separation of concerns than content and layout: Partially, because separation usually is something that happens in the implementation, where they cannot spot it; partially, because things that should be done with separation are not—often with the claim from the software makers that it is easier or more “user-friendly” that way. (Typical office packages and WYSIWYG editors provide good examples of this.)
While MS Office programs, in general, utterly neglect this division, MS Excel goes one worse (as do most or all other spread-sheet programs): Here a three-fold division should rightfully be present, between raw inputs, calculations, and presentation. That these three levels are brainlessly forced together makes Excel disastrously flawed and unnecessarily hard to use.
(A partial workaround is possible by e.g. dedicating one or several sheets to each component of this division. However, this is unnecessarily laborious and the non-expert users are given no incentives to do so—or even a hint that it might be possible or beneficial.)
The following is an automatically generated list of other pages linking to this one. These may or may not contain further content relevant to this topic.