Of all the real-world disciplines that could be used as a guide to web design and development, the practice of architecture is perhaps the best comparison.

Like web developers, every architect is faced with three demands when designing a structure. These demands are often contradictory, and balancing them is part of the art of great design in any practical field. The primary considerations are:

Aesthetics

The look of the work. How does the building appear from different aspects? Is its profile, texture, use of shadow and light pleasing to the eye?

Structure

How will the building be constructed? What materials will be used? Will it stay up? Can it easily be expanded and modified later?

Utility

Does it fulfill the basic function required? (i.e. to house people in relative comfort, keeping the elements at bay).

Everyone who builds things, from architects with fees of millions of dollars to the person living under a bridge with a plastic sheet, has the same basic concerns.

For a website these demands are expressed the same way: does the site look good? (Is it proportional, does it use colours and fonts well?). Is the site constructed in a way that makes sense? (Is the code valid and commented? Does it use semantic markup?) And can the customer / reader do what they need to do on the site quickly and easily? (Find information, add content, order a book – whatever the goal(s) of the website are).

These demands are limited by three factors: time, money, and quality: the familiar “good, fast, or cheap: pick any two” project triangle.

Finally, there are three people in the process, again with competing goals: the contractor/designer, the client, and the customer. The contractor – the architect, in this case – is the designer; the client is likely to be a property developer, and the customer buys the completed house. Both the customer and client are interested in getting the highest quality possible at the lowest cost, but long-term satisfaction and use rests with the customer, no-one else. The designer, on the other hand, wants to fulfill the needs of both the client and the customer, charge a fair amount, and create something he can take pride in.

The primary goal of both the designer and client is to produce something that the end-user wants and can use. To this end, it is very important to divorce your ego from the design process. You are designing what the customer can use, not what “looks cool” (it is possible for a design to be both “cool” and usable, but successful examples are rare).

Be aware that no-one in this relationship may be able to express their desires for what they want to website to be: customers tend to be fickle and reactionary, clients simultaneously over-ambitious and parsimonious, and designers driven by ego.

Most designers are familiar with lorem ipsum, used to create filler text where body copy is yet to be written. Image generators cover the same requirement for graphics: if you know the size and shape of an image on your page, but can’t invest the time to hunt down the perfect illustration, using one of the resources below provides a quick, easy, and flexible solution to create a filler image for a mockup.

Most of the services work on the same basic principle: by passing a series of variables to a URL, you generate an image via a script. For example, placehold.it can take just two variables, height and width, in a URL:

1. <img src="http://placehold.it/150x150"/>

Used in a browser, this generates a grey 150 x 150 pixel image. Most of the generators have the option of using more variables to add further complexity, including controls for color, text, and theme. I’ve divided the generators into three types: monochromatic, color, and novelty.

Color

Most useful for presenting mockups to clients who may not understand that monochromatic fills are simply placeholders, or who require a little more "visual pizzazz".

flickholdr, shown above, pulls pictures from Flickr (with embedded attribution, to keep to the Creative Commons terms of use) for use as placeholders. Generated images are specified by height, width, tag(s) and color.

Lorempixel (previously lorempixum) generates images of any size that correspond to a particular theme (abstract, food, people, technical, animals, nightlife, nature, sports, transport, city and fashion) in color or greyscale.

Random Image Generator creates abstract, vaguely cellular oil-painted images of any size to one of eight palettes. Can generate multiple images at the same time. This is the only service that does not have an API to easily produce images via a URL: instead, the image must be saved and used directly.

Monochromatic

Monochromatic image fills are most practical when you want to concentrate completely on layout, form, and proportion, without the distraction of color or context.

Previously discussed, placehold.it generates single-color filler images, with options for color, interior text, and format (GIF, JPEG and PNG).

DummyImage offers the same options as placehold.it, but adds keyword shortcuts to create images in dimensions of established internet advertising units (for mocking up advertising banners), screen resolutions and video standards.

Novelty

Need a creative change? Novelty image place holders can work… as long as you are sure that your client shares your sense of humour.

Who doesn’t like kittens? placekitten.com generates images of kittens as filler images.

If, on the other hand, you’re more into zombies, there’s placezombies. (We await the inevitable crossover, placezombiekittens).

Color blindness itself obviously can’t be changed by the site designer, but it can be anticipated, and problems avoided, by applying a single simple rule and one tool.

Approximately 7% of North American males are deuteranopic: red-green colour blind. That means that they cannot tell the difference between the two hues: to give you some idea, the banner above shows an image as seen by those with normal vision, and the same image to the right for the deuteranopic.

For designers, compensating for color blindness means adhering to the simple rule “red and green should not be seen (together)”. Red and green can certainly be used in a design, but just as in traffic lights, they should not appear in the same place. Don’t swap a button from red to green to show a change in status, and don’t overlap red and green elements that you intend to be seen as distinct.

There are other, more severe forms of color blindness, but they are very rare, and any designer who at least keeps deuteranopy in mind will tend to develop a site that can be used by everyone, regardless what form of color blindness they may have.

With this rule at hand, creation of your site should proceed as normal, but with the use of tools during the design phase to preview how the pages will look to the color blind. Vischeck is the classic go-to in this regard, with free plugins and simulators to preview how your site and images will appear to the color blind, but there is also colorfilter and coblis (part of the Colblindor site, which contains many more resources on color blindness, as does the WebAIM site). Also notable: Color Oracle, a free Java-based tool for Mac, Linux and Windows that can flip your display into simulations of color blindness independent of any application or device.

Unless you are making a specialized site like Colblindor, don’t try to change the colours you use to make them more aesthetically pleasing for the color blind: doing so will almost inevitably make the palette appear “odd” to everyone else. Rather, follow the process I have emphasized throughout this blog in regards to accessibility: make valid, appealing pages with features that allow everyone to use your site as equally as possible.

In advance of an article on the inspiration and ideas behind the recent redesign of this site, I thought it would be useful to talk about basic redesign principles and strategy.

A lot of people ask me if there is some sort of specific methodology, timeline, or feature checklist for site design or redevelopment. The answer is it’s really a suite of best practices. How, then, do we determine that it is time for a redesign? A few pointers:

The site design no longer serves its users.

As a site evolves, so to do the practices of its users. Look at your web logs: how are people actually using the site? What features do they appear to struggle with, or require but do not have? What content lies unappreciated? What attracts visitors?

Consider browser and device upgrades: the opportunity to dispose of a bunch of hacks and old practices to produce a new streamlined site without abandoning a significant portion of your audience should not remain unappreciated. How many people are visiting your site on mobile devices? What platforms are they using, and how are they interacting with the site? How can they be better served?

Look at page speeds: is the addition of features slowing page load times? Could the features be somehow filtered, or made non-blocking through asynchronous techniques like AJAX? During heavy (>10000 visitors) days, I found that some users were experiencing page load times in excess of 40 seconds; obviously, the site needed to be optimised to cope with increased demand.

Users don’t feel compelled to stay.

Look at your visitor metrics, especially your bounce rates after a big social media push: after coming to your site, how many visitors stay to visit a second page, or a third?

People hitting your site and immediately leaving may not always be a bad thing: they may just get the information they require and go on their way. But most designers seek to extend visitor engagement and interaction: a high bounce rate may indicate that the current design is not inciting curiosity in the average visitor as to the rest of the site’s content. This is exactly what I found with demosthenes.info: many visitors were arriving, reading the page they had landed on, but not exploring further.

When the natural accumulation of features to a site makes it appear no longer organic, but more of a Frankenstein creation: the aforementioned “three chairs and a goat”.

You know the drill. The client comes to you with a proposal: “we’re doing social media now! We’d like you to add a Twitter feed to our site!” And you do it, with a little reservation, and manage to lever it into the design. Over time, more and more features are added. This is natural, and inevitable… but at a certain point, the additions will no longer fit well into the original design. (In an inflexible, poorly developed site, any unplanned additions immediately make the pages look worse). That growing strain cries out for a site reevaluation and redesign.

The “To Do” List is approaching critical mass.

Some changes and upgrades can immediately be implemented in a site, and should be. Others naturally slide into the “nice to have”, “to be considered” and “too hard” baskets. Eventually, it becomes easier to tear the entire structure down and rebuild from scratch, with the previously sidelined features as central considerations, rather than trying to jury-rig them into an established design.

I hope this is a helpful guide to your own site redesign plans. As a very rough guide, I try to consider a redesign of this blog every two years, which means that sketches start 12 to 18 months after the launch of the last version.

Photograph by Alain Delorme, from his “Totems” series

As the relaunch of this site has been receiving positive responses, I thought it might be useful to discuss its design. This will have the secondary goal of indirectly informing my students; my fulltime 1st year classes have a design project coming up, and I lack the opportunity to discuss aesthetics in my (mostly technical) courses.

The redesign of this blog had several goals: not only was a visual refresh long overdue, but the site’s functionality desperately needed improvement. Using the blog as a reference in class, I was aware of the ways in which people interacted and sometimes struggled with the site. I needed a design that was familiar enough to long-term users so as to not completely alienate them, which implied an evolutionary advancement, rather than a revolutionary change.

Design Principles

If the new design had an aesthetic statement, it would be Dieter Ram’s famous dictum “less is more”. I wanted to present a user interface that was clean, uncluttered, consistent, responsive, and easy to use. This site is heavy on content; graphical elements are additions to the design, not features. At the same time, human beings are predominantly visual; I needed a way of attracting the user’s eye and then keep their attention with informative content laid out in a strong, compelling manner.

A useful way of checking a page’s balance is to simply remove the graphics; if the site still holds up, it’s a good indication that you’re neither too content-heavy nor graphically over-the-top. The central rule on the web is that users are attracted by good design but stick around for content.

Keeping to these principles made many of my design decisions for me: I created simple, monochromatic icons using my semantic CSS3 sprites technique, with activation or interest indicated by a subtle deepening of luminosity. Color is used sparingly through the site, concentrated in the headings and banner images of each article (and thus leading the eye inwards to content).

Typography

The previous version of the site used a serif font; in the remake, I decided to use  Erik Spiekermann’s FF Meta Web Pro for body text. I chose Anonymous Pro by Mark Simonsen for code samples, and very occasionally use Blue Highway by Ray Larabie as headline test in article headers, due to the fact that text in that section is often manipulated with a filter to demonstrate the associated lesson, and I needed something thick and solid that would withstand distortion. The relative lightness of FF Meta and Anonymous, combined with a generous line-height, kept the site “breathing”.  I measured all typography in rems, a CSS3 unit of measurement that will be discussed in another article.

Sources of inspiration

The work of German designers, particularly Dieter Ram and Erik Spiekermann, was fundamental to the blog’s design, perhaps most directly the site Spikermann launched with Carolino de Bartolo to promote their new book, Explorations In Typography. The Tumblr effector theme by Carlo Franco was highly influential; the archive feature of Tumblr also inspired this site's archive page. Also: The Genius of Design, a wonderful BBC documentary, together with The Age of Persuasion and Under The Influence, excellent CBC radio shows on marketing.

Before starting a series of articles on how to implement one-page sites with JavaScript, it makes sense to explain the essence of the design concept, which has burgeoned in popularity over the last 18 months.

The traditional architecture of a web site is a series of separate pages: an introduction or index page, an “about” page, an order form, etc., divided up into a book-like format (albeit one that may be read in any order). In a site that undergoes continuous growth such as a blog, this model might be extended through pagination. This standard approach has a number of advantages:

• Dividing site content into clear, logical units makes it easier for users to find the information they are after.

• Page titles can accurately reflect the particular content of the page, adding SEO value.

• Assuming they are well-optimized, each page will load quickly for most users.

Interestingly, the popular design language of the web has recently moved backwards, from a “book” architecture to a “scroll” format. This design is perhaps best currently typified by Pintrest, although there are many variations and ascendants.

Single page sites are exactly that: a lone document that contains all the information for the site. This page may be effectively infinite in length, continuously updated with older information as the user scrolls. While it encourages creative exploration – there are of lot of clever sites that utilize CSS3 parallax techniques and/or JavaScript scroll-position detection routines to keep the user engaged – employing a “one page” design is typically restricted to very particular kinds of sites:

1. The information the site needs to impart is very limited. One-page sites are often promotional, intended to grab the user’s interest rather than conveying complex concepts or large amounts of data.

2. Information on the site is very frequently updated, with new content added every few minutes. Users will see the most recent information added at the top of the page, and will close the site after scrolling past few screen’s worth of content.

There are a few disadvantages to the one-page format:

• At the moment, single-page sites are difficult or impossible for casual users to bookmark. Returning to a one-page site means scrolling until you relocate the information you are after.

• The amount of content in one page sites means that the total file size of the page tends to be very high, making load times long unless the page is very cleverly designed.

• SEO may be compromised: Google will currently index everything that appears on a webpage at the moment the page loads, but it will not index content that is dynamically updated via JavaScript. The Googlebot doesn’t act like a human being: it doesn’t “scroll” down a page, and won’t see content that is added in response to such actions. In addition, Google will always deliver the user to the top of a page: on a single-page site, this means that the visitor will likely have to scroll to find relevant content after landing. The lower down on the page this information is, the more visitors will abandon the site before reaching their goal.

Single page sites do tend to create higher visitor engagement, as the user doesn’t have to find site navigation or make a decision as to where to go next: they just keep scrolling to find new content. But leading the visitor through that content, designing and displaying the information in a captivating and useful way, is an art in itself.

Every site will require different adaptations to narrowing viewport widths: just as there are broad shared design themes between many sites, so is there a range of patterns that might be used as a starting point for adaptive web designs.

Single Column Adaptive Page

The easiest design to adapt to narrow widths. The content container is given a width of 100%; the banner image / logo scales with a max-width of 100%. The horizontal navigation changes size under a media query rule – icons should be at least 45px × 45px for touch devices – possibly wrapping into new lines, or changing from display: inline to display: block. The margins for content decreases, while font sizes alter to retain legibility at small screen sizes.

Two-Column Pattern

Usually reserved for more complex sites. At wide screen sizes, navigation is vertical; as the browser window narrows, UI elements transform into a horizontal orientation.

Three-Column, Single Header Page Design

A design pattern associated with highly organized, “deep” sites (or pages with a lot of advertising, which is an ongoing issue in adaptive pages).  A more complex version of the two-column pattern approach, but with a greater likelihood of using JavaScript (to transform a navigational list into a drop-down menu, for example), together with re-ordering or hiding content.

There are several options for handling the layout of extra complementary content:

1. It may be hidden using display: none, although this has issues for accessibility and SEO

2. It could be filtered by PHP using client detection, and not added as an include.

3. Content could be pushed to the bottom of the page

4. The content could be duplicated on another page that the narrow version of the page links to; the link would be hidden at greater screen sizes.

The second option will often be approached with either JavaScript or CSS3 flexbox, as it frequently involves restructuring the order of page content.

Keep in mind that mobile users increasingly expect a similar experience of a site between their smartphone and desktop computer: if hiding elements at narrow screen sizes, you will want to seriously consider if that content was necessary in the first place. Mies van der Rohe's injunction that “less is more” has never been truer in the age of responsive design.

As the capabilities of mobile platforms keep pace with modern web development, ever-more complex modes of interaction become possible, including “side swipe” or “off pane” mobile navigation of sites. I’ll address those possibilities and many others in future articles; right now, these patterns should help get you started.