Silverfen Web Design

Thoughts — the Silverfen blog

Server side includes 25.vii.2013
The computing involved in a web site is usually split. The address of the website ( in the case of this site) points to a web server whose job is to serve all the files for the site, which typoically include HTML, images, style sheets and scripts. Those files are are received by a web browser running on the computer of the person looking at a web site, and assembled to present the web page.

Server-side includes are instructions in a file of HTML which ask the web server to do something. If the same thing appears on many pages, it is possible to put it in a server-side include, so that it is in fact the contents of one file, inserted in lots of places. A common use of this is for menus on a web site — putting them in a single server-side include means that the menu is the same on all pages, but to change the menu means editing just one file, rather than altering all the files on the site.

The server-side is inserted before a file is served up, so it’s not normally possible to see if server-side includes were used by looking at the source code as it appears in a web browser, but this is a very powerful technique to maximise consistency and ease of maintenance across as web site. I am increasingly using server side includes, typically to hold the heading information, menus, and footer for each page.

An extra layer of subtlety, which rather turns that on its head, is in conjunction with editable web content: instead of saving an entire web page back to the server when editing is finished, it is possible instead to save just the element in the page that has been being edited to a separate file. This comes into its own if other parts of the same page have been dynamically altered because it means those other changes are not saved at the same time as what was being meant to be edited.

Refining editable web content
Earlier in the year I started moving to a new hosting provider, who offer substantially improved facilities, which include access to far more in the way of error messages from the web server.

Previously I had had to be quite cautious about how the editable web content worked because, if there was a problem deploying it on the live site, then that took a lot of intelligent guesswork to sort out. Now that proper error messages are available the guesswork is gone, so it is possible to be far more subtle and sophisticated. The upshot is that I have been able to make the editable web content facility far more sophisticated, with the first site to use the new version going live shortly.

More editable web content 26.x.2011
Having started to deploy editable web content on various websites, I’ve been starting to think about ways this can be extended.

I recently added a “stop press” to the home page of Karine Georgian’s web site as she was appearing on television in a programme about Rostropovich and it struck me that another extension of the editable web content facility is to allow content to be added that disappears automatically on a specific date — in this instance it would have been possible to add the “stop press” using editable web content, and include in that a date on which it would automatically disappear.

It will be interesting to see what other uses the editable web content can be put to.

Maintaining CMS-backed web sites 1.viii.2011
I’ve just spent rather longer than I was expecting updating the software for a website implemented in the content-management system (CMS) Drupal.

The article CMS or not? on this web site outlines some of the arguments that are around in deciding whether or not to use a content management system. The hidden extra for many of these systems lies in keeping both the core software, and all its additional modules, fully up-to-date.

Up to a point this doesn’t matter. If a site does what is needed then maybe keeping the behind-the-scenes software up-to-date may not matter — in just the same way that someone doesn’t have to replace the computer that meets their needs just because a newer one has been released.

But, alas, protecting one’s clients’ interests points in another direction. Some of the updates fix security holes — places where the people supplying CMS software have discovered that it is possible for third parties to break in to a site or damage it in some other way. It is important to attend to these things, but it often feels like investing effort because other people made mistakes.

If a site gets seriously out-of-date then there can be problems when something new is needed. In Drupal, for example, it’s normally only possible to go from one major version to another (so from version 6 to version 7). If a site is seriously out-of-date, then the intermediate versions may be missing: so upgrading from verion 6 to version 7 is fine, but upgrading from version 3 to version 7 is a problem if (say) versions 4 and 5 are no longer available.

The upshot, alas, is the reasonably-frequent upgrading of CMS-backed systems is a reasonably normal part of life, if a little frustrating.

Email newsletters
There was a time when email newsletters were widely advocated. It made perfect sense for organisations to have a web site and to actively send out email newsletters from time to time. It provided a neat solution to the problem that web sites tend to be passive: an organisation puts up a web site, but has no way to cause people to visit when new things are added.

As an idea, that has a good measure of wisdom. It’s led many organisations to invite people to sign up for newsletters, or to do more ingenious things to get email addresses — more-or-less with consent for them to be used. It is also possible for larger organisations to hold information on people, and send out quite targeted newsletters.

There are some delicacies about how this relates to data protection legislation, and I suspect that people sometimes sail close to the wind.

Entirely unsolicited email — spam — is a major nuisiance, and most email newsletters try to avoid falling into that category, not least by providing a means to opt out of future mailings.

But I am not alone in receiving vast quantities of email. Much of it is from organisations where I have bought something in the past, and from whom I might buy things in the future. The snag is that overly frequent email newsletters can cause real annoyance. It’s hard to measure the commercial consequences of this. If an organisation sends out a newsletter and a flurry of people buy things, there is an apparent success, but it’s not immediately clear how many people then start thinking ill of the organisation for bombarding them with unwanted email — or (as I tend to do) have a filter on their email whch sends the most frequent newsletters into a “bulk” folder that is then largely ignored.

But email newsletters can still work. The crucial thing seems for their recipients to see them as interesting. It’s easy for the sender of a newsletter to be so focussed on what they want to communicate, that they loose sight of how that communication will be received.

The trick seems to be to use email newsletters very sparingly, so that they recipient’s first reaction is “I’ve not heard from them in a while” rather than “not them again”, and brief, so the whole newsletter can be read in a moment. In practice that typically means small amounts of text which entices people to read further on a web site.

There’s also an interesting mental trick. If the sense is that a web site is at the heart of an organisation, then communication via the web site is natural, which is likely to lead to a web site which people re-visit often. That minimises the need for a newsletter, and makes the ideal newsletter one that is a short reminder of the organisation’s existence. That is also the type of newsletter that is least likely to be counterproductive.

If, instead, the sense is “we’ve got to get them to buy our products”, although the feeling can be upbeat and entrepreneurial, the message communicated easily alienates the very people on the edge of an organisation’s circle of influence who a good marketer will want to reach.

Fonts 15.iv.2009
If a document is sent electronically to a print shop, it normally goes with all the fonts embedded, so the designer can be confident that what will be printed is what is expected. Buying additional fonts is a familiar part of most type designer’s lives.

Life’s a little different in designing web sites because the designer specifies the font to use in the site’s style sheets, but that font is only used if it is on the machine of the person viewing the site. In principle it is possible to design a page where the browser, on finding that it hasn’t got the right font, downloads the missing font from a web site, but this effectively means a font being given away for free, so it usually represents a breach of the copyright license for the font.

What most designers do is to specify a list of fonts, starting with what they actually want, and working down a series of alternatives, ending up with “sanserif” or “sanserif”. This is an elegant solution, but presents problems because the number given as the size of a font actually refers to the size of the block of metal on which it would have been cut in the days of movable type: to make life worse, the ratio of the height lower case letters like “x” to the capitals (x-height to cap height) varies from font to font, so that using a different font at the same specified font size can produce text looking markedly smaller. One solution to this is font-size-adjust, which is a very helpful variable specifing the ratio of cap height to x-height, so that the browser can make subtle changes to font sizes if it has to start substituting: it was a little frustrating to upgrade Firefox a while back and find the processing of this had been broken, so I had rapidly to comment out uses of this in my web sites. Sadly I’ll have to wait a while before uncommenting those so I can be reasonably confident that people will have upgraded.

Different font families are available on different machines, so it is sometimes necessary to be quite imaginative and not so much to use the closest available face on one platform (which may not be very similar), as one that will have a similar emotional response in the viewer.

One of the querks of this is that one has surprisingly little control over how many letters will appear in a block of text of a specified width: it can be really surprising to see how much variation there is in the same web page viewed on different machines, so I often end up designing pages thinking about abstract ideas of how the text should flow, rather than trying to use what I think I know about how it will behave so that it behaves as well as it can under all circumstances, rather than falling over if it hits a machine where the fonts are significantly different from what I expect.

Screen sizes 25.ii.2009
One of the silent changes of recent years has been the arrival of flat, thin film transistor (TFT) monitors, which are a specialised for of liquid crystal display and have largely replaced cathode ray tubes in shops.

There are lots of benefits in the change, as the new monitors are lighter, less bulky and less heavy. From the web designer’s perspective the other major change is that they are bigger. On my last trip to PC world, the smallest I could see was 19”, offering a resolution of 1366 by 768 pixels.

People don’t automatically buy new monitors — or new computers — simply because they are available, but this does mean that that the size of screen that people can be assumed to have is going up. There’s an old text-setter’s rule-of-thumb that justified text looks best on 60 characters per line. There was a time when this meant web sites had to assume that there was not much spare space besides and perhaps some navigation to one side. Now that the proportion of people with wider screens is rising, there’s scope to let this influence web design. I’ve always designed sites so that they work if viewed on a wider window than I expect, and I am pleased that sites designed a while back work well on the wider monitors, but as these become more normal, some interesting possibilities are opened up.