With the advent of widely deployed content management systems (CMS) and higher use of the web to present content than ever before, a lot of users are finding themselves in front of a variety of tools to present content on the web. There’s one recurring problem, however: how do you get the job done in the most efficient and sustainable way, while taking organizational business factors into proper consideration?
There used to be one person in charge of the process of posting things to the web; now there are frequently 5, 20, or even more. There are limitations on disk space; there are costs associated with moving things to the web, and even more-so in secure environments. With increasing numbers of information suppliers, and an increase of those who demand said information, the importance of understanding web content optimization and presentation strategy becomes even more important as every piece of information uploaded has the potential to relate to another piece of information and create emergent value.
Lately I have been involved in planning an intranet for the organization I work for, BC Stats. This has involved some information architecture (sitemaps and linking), user experience, content strategy, organizational engagement and communications coordination. What I forgot in this process is that not everyone has the understanding of preparing content for the web that I do as someone who has been making websites since 1994 on the Victoria Freenet, a time that had severe file size and bandwidth limitations – ie 5MB for an entire site, and audiences that were on dial-up (phone line) internet. Although archaic in web terms, the Freenet experience prepared me well for working in scalable demand web based environments for every year that followed. It was during this time that I learned content preparation inside out by reading books at the library on file compression, experimenting with my own site, and conversing with others that were largely responsible for launching the web as we know it.
This is the least technical and most user oriented piece in this writeup about preparing content for the web. A content strategy at it’s most basic level will consider how the information that needs to be disseminated will be presented to the reader. How will the reader know they’re in the right place and will find the right information when they get to the page you have created? What sort of narration do you want to provide throughout your site? How are you speaking to your audience and ultimately how are you providing value with the information you need to present? A content strategy does not need to be exhaustive, but should consider some communication fundamentals, such as telling the reader what they’re going to find on the page in front of them, a consistent format for presenting pages of similar information (think processes or different types of resources), and alternatives for special types of content, ie infographics. For a blog’s content strategy, you might include ways to position the organization or person blogging – ie, if a statistics organization needs to appear to be experts, they could write about methodology. Or a photographer could write articles about aperture or the inverse relationship between ISO performance and megapixel count. Good content strategy takes the user’s perspective in as well as the writer’s. Why post information if you don’t know why people would want to access it? Ultimately a content strategy ensures you are delivering value in a relevant way to your users as well as yourself.
What is a web based environment and how is it different than a network drive?
There are many considerations that will make the Intranet experience different than a network drive experience. For now, I will elucidate on the following:
- Web servers
- Optimization practice
A couple years ago I was at a party and met a very confident man who had built his own identity around that of being a web designer. I usually feel a sort of an unspoken kinship with other web designers and I enjoy talking shop, so I channeled Ali G and asked what initially appeared to be a rather obtuse question: “What is the best HTML element?” My new friend scoffed at the question, saying that it was impossible to answer. I have to admit, when I asked him, I didn’t even know the answer, but the question was irresistible to answer, especially in a time when HTML5 itself continues to evolve as new elements continue to get added. We talked about Embed, H1, IMG, but I concluded that “A” had to be it. “A” is short for anchor, and any text or image inside of it becomes clickable. When the “href” attribute (short for hyper-reference) is added, it makes a click on that text or image lead to the value set by the “href” attribute. Instead of documents living in a series of vacuums, they connect. They are bridged; they have arteries; they connect. And what becomes possible? Search couldn’t work without links. Each result is a link which relies on the “A” tag. Google wouldn’t exist without the A tag. That was it; linking matters.
Although you can certainly link from document to document on a network drive, how often is it actually done effectively? The traditional expectation of a word document is to find a wall of text that may reference other documents or may not. Because some of these documents are meant to be printed, authors have constrictions about exactly how well they can reference other documents electronically. Although the documents that will live on an Intranet should be able to be printed, the expectation is that printing will no longer be necessary, and as such, authors of these documents will be freer to link documents together. This is especially important when we consider types of content such as process documents, many of which reference each other, ie “if this then that” – the “that” can be a link to another document rather than including every possibility in a process tree in a single document. This leads to leaner documents that are updated faster and easier, as well as less redundant information in multiple files, when increases the functional integrity of the data or information you are presenting.
Files are served from a web server. If you don’t regularly work in a web environment, what this means is that all the content you are looking at is stored on a computer somewhere on the network. When you click on a link to a page on a site, what you are actually accessing is a file (or a rendering of a file) that lives on that computer – that computer is called a server or web server. It’s serving you pages or files that you request. It doesn’t sound like that big of a deal, and it’s not sounding very different than a network drive, until you consider that each request you make of that server (by clicking on links or searching) scales with the amount of users doing the same thing as you at the same time. You know how your computer takes a few seconds to open up a word document after you double click on it, or a few seconds more if the document has a large file size? Your computer is using processing power to access the file and open it up. A web server must multiply this experience for how-ever many users need to access files or documents at once. Ergo, file size matters, which leads us to optimization for the web.
We can optimize almost everything to reduce loads on web servers and speed things up for our users, as well as make the site more sustainable by taking up less disk space on the web server itself.
Text – writing or pasting in plain text is optimal because there is no hidden HTML code that could be imported from a program such as Microsoft Word. You may have heard many times that you should paste as plain text as much as possible between programs. This is especially true for the web, where extraneous HTML code from desktop publishing software can literally make a document ten times the size without providing any additional value whatsoever. Adobe Dreamweaver has an option in the commands menu, for example, that is “Clean up Word HTML.” It would be better if there was no HTML from Word to begin with. For the most part, pasting plain text into a web editor is fast, and re-applying heading classes only takes a few moments. It is relatively painless and a best practice to paste in plain text.
Images – Files can be compressed and resized to best display on the web. For images, your choices tend to be JPG/JPEG, PNG and GIF. Each compression method has a purpose, which I will explain below. Note: In order to understand the following, you must understand what a pixel is.
- .GIFs restrict the colours in an image to 256, which is inadequate for photos, but GIFs can include transparency. GIFs are good for images that have a low number of colours (many logos are this way) but ultimately the GIF is a novelty format because PNGs can include transparency (and are better at it) and have no limit on numbers of colours.
- .JPGs have no limit on numbers of colours and compress images on a sliding scale of quality when saving the file as a JPG – ie you can save an image as a JPG with a quality setting of “20” and you’ll have an image with a very small file size, or you could save it with a quality setting of “100” and the file size would be much larger. The downside of turning down the quality slider too far is that the image gets visibly degraded the further you pull the slider down. It gets chunky in appearance the closer to zero you get. This is the compression algorithm clustering similarly coloured and shaded pixels together, saving that range of pixels as a piece of information in the file rather than saving information about each individual pixel in the image file. That is how JPGs compress. I have found that the best setting for optimizing for the web in Photoshop is putting the slider between the 60-70 around and eyeballing it for unwanted blockiness. If it is too blocky then I simply slide the quality setting upward.
- .PNGs (portable network graphic) are my favourite format for the web as they can include alpha transparency and any number of colours. You do need a quality slider because the compression method with PNGs does not use the same algorithm to reduce file size. The PNG file is almost always smaller than the original uncompressed file, be it a BMP, TIFF, RAW etc. PNG is generally a good web format choice no matter the circumstance.
I have found that image sizing is a confusing subject for a lot of people. Some of the confusion I hear about this with regularity is around file size – ie what is a good file size, and also – when we are talking about file size, how are we talking about the size of the image – ie, are we talking dimensions (800 pixels high x 1200 pixels wide) or are we talking file size (1mb or 8 mb)? The reality is that we are talking about both of these things and in different ways. Generally, unless you are in the business of selling photography, you don’t need to put up a 8000×12000 pixel image, and you can safely re-size the dimensions of the image to match the width or height of the container or page that it resides in on the web page that you wish to have it displayed it on. Some modern interfaces, such as Facebook, will take any size image and resize it for you on their servers. They are doing the optimizing for you, but many web services will not do this, or pretend to do it but do an inadequate job, ie overcompression of the image resulting in image artifacting (which makes people’s faces look blocky), or falsely resizing where they use CSS to change the dimensional appearance of the image, but the file dimensions remain the same on the server, and as such, the strain on the server for every request remains the same.
Other Documents – PDFs can be compressed for the web. If you are using Adobe Acrobat Writer, there are export options for printing (larger file size), web & screen (smaller) and some other options that are somewhere in between. Find and use these options to your advantage.
Last point on optimization
Remember, web servers are just computers that sit on a network and have been designated as responsible for fulfilling requests that are made through a web address. Besides cloud based server solutions (which many organizations do not have the option of using), most web servers have finite disk space and processing powers. Reducing the amount of power they must use per request means that the system will be faster for all users, ie your audience and you. The side benefit of optimizing content for the web is lower costs because you are using less disk space on the server (if you do not have an unlimited disk space plan) and you’re not forcing the web server to use more bandwidth (a measure of transmission of data – this has its own costs associated with it, as those with smartphones are quite aware of) than necessary.