The website as a signal


We rarely think about our website as a signal, which affects the quality of our design. Every time we add an element to a page, we influence the signal at a particular point in time. Every time we remove from it, we eliminate part of the signal. Imagine a singer recording their latest song in a noisy environment and then selling it. Any listener who perceives the noise would be reluctant to buy another album from the same artist again. After reaching a perceivable threshold, the noise becomes intolerable.

What about CSS? It is common to see many different selectors to contain the property “position: relative”, “float: left” or “display: block”. We are duplicating these properties, creating the same signal segment at multiple places. We could choose to combine multiple selectors and assign a single property to them, which gives us some flexbility in the way we can mix them at the expense of possibly matching the same elements multiple times, for every property they have (again, duplication). Like HAML, SASS also helps us write less, but also doesn't eliminate duplicates in the final signal. The more powerful ways we have to shape our information, the more redundancy we can expect to create.

Each pixel on the screen has been produced by a signal that the graphics card is sending to the screen. Every image is a signal with red, green and blue components that we could access and manipulate separately (but which can become quite CPU intensive for large images). We choose at any given moment how to paint the small amount of the pixels on the screen. This means that the website shows a signal. When we start scrolling, it can either be continuous (smooth) or discrete (janky). We generally strive for continuous signals. If someone creates a long HTML form and divides it into multiple pages to make it more manageable for the user, they are probably creating a discrete signal, not a continuous one. This allows them to hide which information they require under the mask of a simple username&email form. Once the user fills the two fields, they are asked for 15 more, where there was no previous indication that this would happen. Now the site owner has some information and doesn't need to provide anything for it. This is both discrete and disrespectful, but in my experience, it happens quite often on the web. If the user needs to click multiple times in short bursts, for instance, to move between the various steps in the form, this is both discrete and tiring. Everyone who has tried to download a driver from a hardware provider and had to first choose manufacturer, then OS, then device, then serial number, driver version and so on, can probably confirm this.

An important aspect is to choose the most effective representation for the data, e.g. to encode the signal in the most effective way. For instance, if we intend to output data that has tabular nature, it is probably not a good idea to store it within a hierarchical data structure. We could use a NoSQL database like MongoDB (hierarchical) to extract data into a <table> on the page, but this would be less efficient than using an SQL database that has been made specifically for this purpose. Here it is important to examine how the database is encoding the data internally, to see the quality of the signal. For instance, MongoDB uses a lot of ,” symbols, and a repretitive JSON-like structure is less efficient than the CSV format. In each document the properties are duplicated and it is not possible to list all values after a single property instead. All this (at least on the surface) creates a signal with a lot of redundancy, so we can expect that working with such a signal would be slower compared to one from a relational database. Even if MongoDB can impress with speeds of a couple of milliseconds, we should not forget that this is within the DB management application. When the data reaches the web page the situation might be quite different.

Signals have frequency and amplitude. The amplitude indicates how strong the signal is at a given point in time and how abruptly it transitions to a later state. This means that we need to consider how smooth we lead the eye from one element/state to another, evaluating position, size, color and shape. How things coexist on the page can be as important as their exact nature. In the case of blinking, we repeatedly and abruptly alternate between the values 0 and 1 (invisible and visible), which is bad. Instead we should have moved from 1 to 0.99 to 0.98 and so on with each value corresponding to a different segment of the signal.

If our page is a signal and the signal is a function, this means that we can combine it with other functions to arrive at new ones. For instance, we can use a template engine to create a template (one function) that we use to populate with data (another function) to receive the final page (resultant function, h(z)= f(x)&middot;g(y)). We can think in terms of a superposition of multiple functions and tweak their individual parameters to see how the whole would behave. This gives us a lot of flexibility to arrive at a signal we want.

A signal can also be transformed. In the equation h(z) = f(g(y)), f is our transforming function that receives a web page (the function g(y)) as a parameter. Web scraping, where we extract portions of a page and place the data in a new context would be an example of this. The transforming function itself may not work universally with any given page by default, since we may want to extract very specific fragments from individual pages with highly varying structure. Getting all data could lead to space problems and will increase the computational effort needed to analyze it. Again, we should remember that we seek the sparsest possible representation to complete our task. The possibility for transformation means that the information we provide to our users will likely not remain in its original form. That is, we should allow for the signals we produce to be easily transformed by an arbitrary transforming function picked by the user. If you remember XSLT, then you know that it was used to transform XML. Providing a service API publishes our transforming function to everyone who wants to send signals to it and wait for the response. (APIs usually limit the frequency at which this could happen to prevent abuse).

If a team of four people works on a single website, then this means that 4 functions are influencing each other at any given point, which may affect the consistency of the signal that is communicated to the user. If he/she perceives the message differently while moving from one page to another, they will ask themselves whether this is still the same site. It may look similar, but it may not feel the same.

There is no reason to be proud of having 50000 lines of CSS on our website. This is a sign of avoiding to treat it as a signal. Over time the redundant components will add up and maintenance will become increasingly harder, converting our “advantage” into disadvantage. If you mess with the signal, it will bend you.