Category Archives: Responsive Web Design

wordpress-checklist

The Killer WordPress Checklist

So, You are working on a WordPress Project? Awesome!

It’s a big struggle in remembering the steps involved in setting up a WordPress website.

And we soon realized that, there were hardly any checklists that covered all the aspects of WordPress together!

That’s when we decided to create “Killer WordPress Checklist” that would cover everything from the pre-launch directions and development process, to SEO, maintenance and security.

Honestly, this checklist has worked wonders for us and hope it does for you too!

Wordpress Development Checklist

[via Capsicum Mediaworks]

All That Glitters Is Not Gold: A Common Misconception About Designing With Data

Too often when working in information design, you’ll hear the request, “Can you make the data look cool?” “Cool” is a rather ambiguous term, and means different things to different people. Unfortunately, when working with data, the term “cool” is often directly juxtaposed with common charts like line, bar and pie, which are often relegated to the backbench, and written off as “boring.”

The emphasis on the instant visual appeal of an infographic over the clarity of the presentation of data is a troubling trend that plagues the modern incarnation of the infographic.

Data Visualization And The “Cool” Factor

“The important criterion for a graph is not simply how fast we can see a result; rather it is whether through the use of the graph we can see something that would have been harder to see otherwise or that could not have been seen at all.”

– William Cleveland, Web Application Design Handbook

When presenting data visually, our main aim should be to look for ways to effectively communicate the stories hidden in the depths of the spreadsheet. Data visualization grants a means for discovery. It frees the data from the confines of its tabulated raw format and provides a way for the viewer to see trends, gather insights and understand complex stories without the need for words.

However, the average infographic that you’ll likely come across online today focuses more on the overall aesthetic of the piece, the “cool” factor, than on the data itself. “Info-posters” that are heavily illustrated and have a low information-to-pixel density currently dominate the infographic landscape, many of which dumb down data and spoon-feed the audience a choice set of factoids for easy digestion of the chosen topic.

infographicx3
In an effort to make the data appear more interesting, some infographics use design elements to distract the viewer. Large view.

In striving to achieve coolness, the examples above forgo the integrity of the data and, hence, the main function of the infographic. The design, rather than clarifying the data, actually distracts the audience from the information presented, encouraging them to engage with the visual elements rather than with the data itself.

Data Vs. Design?

Now, that’s not to say that being informative and beautiful are mutually exclusive. There are many wonderful examples of data being presented in an efficient, effective and visually stunning way. But the beauty of most of them lies in their simplicity.

Screen Shot 2013-07-12 at 12.15.56
US Gun Deaths” by Periscopic. Large view.

The most effective infographics and visualizations present data as clearly and concisely as possible, free from most distractions and embellishments — the emphasis being not on making the data look cool, but on ensuring that the data’s story is clearly communicated.

Decisions made during the design process will either help or hinder the viewer’s comprehension of the subject matter. So, although it is often said that the type of data will determine the type of visualization, design choices involving color, shape, layout and typography are also extremely important and will affect the ease with which the information can be understood. For example, color can highlight key insights, size can demonstrate change, and proximity can imply correlation.

A common misconception is that the audience will be interested in your data only if it looks exciting and is broken down into bite-sized chunks. In reality, you don’t need to dress up the data to make it more interesting. The information in the graphic, or the story you’re revealing, will ultimately determine the appeal of the piece, not the fancy illustrations. As Brian Suda puts it in his book Designing With Data, “Graphic design is not a panacea for bad copy, poor layout or misleading statistics”.

Bar Charts Are Your Friend, Not Your Enemy

When the focus is on communicating data effectively, common chart types should not be dismissed as boring alternatives, and you certainly shouldn’t be afraid to use them when telling stories with data.

News organizations such as The New York Times and The Guardian rely heavily on these common chart types, because simplicity and efficiency will often trump novelty in conveying complex information to a wide audience.

Screen Shot 2013-07-12 at 12.23.00
Why Is Her Paycheck Smaller?” by The New York Times. Large view.

Charts such as line, bar and pie have been in constant use since the 18th century for good reason. How information is displayed and organized in these charts appeals directly to the intrinsic way in which humans perceive things. According to the Gestalt laws of perception, the human brain automatically organizes and groups the things it sees by proximity, similarity, continuity and symmetry.

Designing with data in a way that supports these relationships (for example, by using color to show similarity, or by using a connecting line to imply continuity) makes it easier for viewers to understand what the data is showing and to draw certain conclusions that would be a lot harder to come to had the data been merely displayed in tabular format.

According to Andy Kirk in his book Data Visualization: A Successful Design Process, by presenting data in a visually effective way, you “move from just looking at the data, to actually seeing it.”

In Practice

The following “infographic” was probably the unfortunate result of a designer being asked to make the data look cool — a predicament I can certainly sympathize with, having been given the exact same creative direction in a number of projects. On more than one occasion, I have been explicitly asked not to use bar or line charts and been told that I simply needed to “jazz up the data,” much to my concern.

The presentation of the information below certainly is unique, and effort has been exerted to make the information look interesting. The graphic fails, however, in actually conveying information.

Screen Shot 2013-07-12 at 12.25.53
Top 10 Salaries at Google”: Making the data appear more interesting does not necessarily make it any easier to understand. Large view.

This graphic’s primary purpose should have been to present the data in a format that is easier to read than a table.

Screen Shot 2013-07-12 at 12.29.58
Large view.

In this instance, however, the table functions more efficiently than the graphic as a way to explore the data. If the salary range for each job was not present in the graphic, it would be nigh impossible to read. The pie-chart format adopted here actually obscures the data, rather than makes it accessible. Additionally, the colors are somewhat confusing; the radius of the pie slices are meaningless; and the number and size of the people figures don’t seem to correspond to anything.

(Update:The number of people figures in fact relate to whether that role involves two salaries. The double-salary category is in itself problematic, as it’s not completely clear whether those salary ranges relate to one salary or the sum of both salaries for that role. Additionally, the usage of multiple people figures to illustrate the double-salary point is also misleading. At first glance, this particular use of iconography could imply the number of people associated with that role, rather than its intended use of demonstrating number of salaries per role. Perhaps a different icon to represent salary is needed in this instance.)

So, how could this be better visualized? Focusing first and foremost on the clarity of the data, I’ve explored just two possible ways in which this small data set could have been presented. I’m sure there are many, many more.

SmashingMag1_ChartRedesign-03
One possible alternative to the infographic above. Large view.

This first option gives the viewer a much clearer representation of the data. With the linear organization, the viewer can understand at a glance what the data is showing, without having to work too hard. In stark contrast to the original, this graph makes the data instantly accessible, allowing for easy comparison between the jobs.

The first complaint I would likely hear is that the graph has an abundance of empty space. This space, however, actually tells a big part of the story. On the one hand, we’re presenting a comparison of 10 jobs; on the other, we also want to highlight that these salaries are actually very high, and the white space reinforces that.

Alternatively, the data could be presented as a slope graph:

SmashingMag1_ChartRedesign-04
Any one data set can be presented in a number of ways. Large view.

Here, we’ve zoomed into a portion of the graph. On the left side, markers pinpoint the low end of the salary range; on the right, markers pinpoint the high end. This version more clearly highlights those jobs with the widest ranges in salary, and it shows us that different presentation methods can tell slightly different stories.

These two examples may not have the visual pizazz of the original, but unlike the original, the data and the story are easily accessible to the viewer and not hindered by the motivation to look cool.

The request to simply make data look interesting is all too common in information design, and it might seem innocent at first. But if you forgo the integrity of the data to achieve this goal, then you run the risk of turning your infographic into merely a graphic with information, and that’s a big difference.

All that glitters is not necessarily gold.

(al) (ea)

Part Two: How To Fix The Web: Obscure Back-End Techniques And Terminal Secrets

Just a little reminder before you start: In part 1 we explored the infrastructure of the Internet and the make-up of a Web server. We left off at the stage where our Web server software is up and running again, and we’ve just double-checked this by telnetting an HTTP request and received the successful response code. It’s now time for…

Finding Your Website

The 200 code means that your home page is okay, and you should be able to visit it in your browser. However, it may not show what you expected, and your fabulous Widget 3000 page may still be absent.

Virtual Hosts and Streams

As mentioned above, many servers host multiple websites. One of these is the default website. It is the website you get when you visit the server by IP address http://80.72.139.101/ instead of by name, or when you leave off the Host: line in the HTTP request while telnetting. The rest of the websites are known as virtual hosts. Every one of these websites has a physical location on the server known as its document root. To further investigate your website woes, you need to discover its document root.

Fortunately and sensibly, most server management packages like Plesk store their virtually hosted websites according to their domain name, so you can usually just find directly on the domain name. The / in the command below tells find to search the whole file system, the -type d looks only for directories, and the -name part searches for any directories containing “smashingmagazine”. The asterisks are wild cards. You’ll need to either escape them *smashingmagazine* or put them in quotes “*smashingmagazine*”:


$   find / -type d -name “*smashingmagazine*”
find: ‘/var/run/cups/certs’: Permission denied
find: ‘/var/run/PolicyKit’: Permission denied
/var/www/vhosts/smashingmagazine.com
/var/www/vhosts/smashingmagazine.com/httpdocs...

If you run this command as a normal unprivileged user, you will probably see lots of “Permission denied” as find tries to explore forbidden places. You are actually seeing two types of output here: stdout for “standard output” and stderr for “standard error”. They are called output streams and are confusingly mixed together.

You have already encountered the pipe symbol | for piping the output stream (stdout) of one command into the input stream (stdin) of another. The symbol > can redirect that output into a file. Try this command to send all the matches into a file called matches.txt:


$   find / -type d -name “*smashingmagazine*” > matches.txt
find: ‘/var/run/cups/certs’: Permission denied
find: ‘/var/run/PolicyKit’: Permission denied...

In this case, all the stdout is redirected into the file matches.txt and only the error output stream stderr is displayed on the screen. By adding the number 2 you can instead redirect stderr into a file and just display stdout:


$   find / -type d -name “*smashingmagazine*” 2> matcherrors.txt
/var/www/vhosts/smashingmagazine.com
/var/www/vhosts/smashingmagazine.com/httpdocs...

There is a special file on Linux, UNIX and Mac computers which is basically a black hole where stuff gets sent and disappears. It’s called /dev/null, so to only see stdout and ignore all errors:


$   find / -type d -name “*smashingmagazine*” 2> /dev/null
/var/www/vhosts/smashingmagazine.com
/var/www/vhosts/smashingmagazine.com/httpdocs...


The end result is that this find command tells you roughly where your document root is. In Plesk, all the virtual hosts are generally stored within the /var/www/vhosts directory, with the document roots in /var/www/vhosts/domain.com/httpdocs.

The Long Way

You can find the document root more accurately by looking through the configuration files. For Apache servers, you can find the default website’s document root by looking through the main configuration file which is usually /etc/apache2/apache2.conf or /etc/httpd/conf/httpd.conf.


$   grep DocumentRoot /etc/httpd/conf/httpd.conf
DocumentRoot “/var/www/html”

Somewhere inside this conf file will also be an Include line which references other conf files, which may themselves include further conf files. To find the DocumentRoot for your virtual host, you’ll need to search through them all. You can do this using grep and find but its a long command, so we will build it up gradually.

First, we will find all the files (because of the -type f) on the whole server (the /) whose names end in “conf” or “include”. The -type f finds only files and the -o lets us look for files ending in “conf” or “include”, with surrounding escaped parentheses. As above, the errors are banished into the ether:


$   find / -type f ( -name *conf -o -name *include ) 2> /dev/null
/var/spool/postfix/etc/resolv.conf
/var/some file with spaces.conf
/var/www/vhosts/myserv.com/conf/last_httpd.include...

This is not quite complete as any files with spaces will confuse the grep command we are about to attempt. To fix that you can pipe the output of the find command through the sed command which allows you to specify a regular expression. Regular expressions are a huge topic in their own right. In the command below, the s/ / /g will replace all spaces with a slash followed by a space:


$   find / -type f ( -name *conf -o -name *include ) 2>/dev/null | sed ‘s/ / /g’
/var/spool/postfix/etc/resolv.conf
/var/some file with spaces.conf
/var/www/vhosts/myserv.com/conf/last_httpd.include...


Now you can use a backtick to embed the results of that find command into a grep command. Using ` is different than | as it actually helps to build a command, rather than just manipulating its input. The -H option to grep tells it so show file names as well. So, now we will look for any reference to “smashingmagazine” in any conf files.


$   grep -H smashingmagazine `find / -type f ( -name *conf -o -name *include ) 2> /dev/null | sed ‘s/ / /g’`
/var/www/vhosts/smashingmagazine.com/conf/last_httpd.include: ServerName “smashingmagazine.com”...

This may take a few seconds to run. It is finding every conf file on the server and searching through all of them for “smashingmagazine”. It may reveal the DocumentRoot directly. If not, it will at least reveal the file where the ServerName or VirtualHost is defined. You can then use grep or less to look through that file for the DocumentRoot.

You can also use the xargs command to do the same thing. It also allows the output from one command to be embedded into another:


$   find / -type f ( -name *conf -o -name *include ) 2> /dev/null | sed ‘s/ / /g’ | xargs grep -H smashingmagazine
/var/www/vhosts/smashingmagazine.com/conf/last_httpd.include: ServerName “smashingmagazine.com”...
$   grep DocumentRoot /var/www/vhosts/smashingmagazine.com/conf/last_httpd.include
DocumentRoot “/var/www/vhosts/smashingmagazine.com/httpdocs”

The end result, hopefully, is that you’ve definitively found the document root for your website.

You can use a similar technique for nginx. It also has a main conf file, usually in /etc/nginx/nginx.conf, and it can also include other conf files, however its document root is just called “root”.

Apache Control Interface

With Apache, there is yet another way to find the right conf file, using the apachectl or newer apache2ctl command with the -S option.


$   apachectl -S
VirtualHost configuration:
80.72.139.101:80       is a NameVirtualHost
         default server default (/usr/local/psa/admin/conf/generated/13656495120.10089200_server.include:87)
         port 80 namevhost default (/usr/local/psa/admin/conf/generated/13656495120.10089200_server.include:87)
         port 80 namevhost www.smashingmagazine.com (/var/www/vhosts/smashingmagazine.com/conf/last_httpd.include:10)...

If this whizzes by too fast, you can try piping the results through grep. It won’t work, however, because grep only operates on stdout and for some reason apachectl outputs its information to stderr. So, you have to first direct stderr into stdout and then send it through grep. This is done by redirecting the error stream 2 into the output stream 1 with 2>&1, like this:


$   apachectl -S 2>&1 | grep smashingmagazine
         port 80 namevhost smashingmagazine.com (/var/www/vhosts/smashingmagazine.com/conf/13656495330.08077300_httpd.include:10)

This also reveals the conf file which contains the DocumentRoot for this website. As above further grep or less will reveal the DocumentRoot.

Checking the Document Root

Now that you’ve found the document root, you can snoop around to make sure it’s alright. Change to the directory with cd:


$   cd /var/www/vhosts/smashingmagazine.com/httpdocs
bash: cd: /var/www/vhosts/smashingmagazine.com/httpdocs: No such file or directory


If you get the error message “No such file or directory”, that is bad news. Either the DocumentRoot has been incorrectly set or your whole website has been deleted. If it is there, you can list the files with ls. The -a also shows hidden files which start with a dot, and -l displays them in long format with permissions and dates:


$   ls -al
drwxrwxrwx  8 nobody  nogroup  4096 May  9 14:03 .
drwxr-xr-x 14 root    root     4096 Oct 13  2012 ..


Every folder will at least show these two entries. The single “.” is for the current directory and “..” is for the parent directory. If that’s all there is, then the directory is empty.

While you’re there, you can double-check you are in the correct place. Create a new file using echo and again using the > symbol to send the output to a file.


$   echo “<h1>My test file</h1>” > testfile.html

This will create a file called testfile.html containing a bit of HTML. You can use your browser or telnet or curl or wget to see if the file is where it should be.


$   curl http://www.smashingmagazine.com/testfile.html
<h1>My test file</h1>


If that worked, then well done, you have found your website! Remove that test file to clean up after yourself with rm testfile.html and keep going.

Back up and Restore

The tar and zip commands can be used to back up and restore. If your website is missing, then restore won’t help you much unless you have previously backed up. So go back in time and backup your data with one of the commands below. To go back a whole day:


$   gobackintime 86400
It is now Sat May 10 20:30:57 BST 2013

Just kidding — but it would be nice! The tar command stands for tape archive and comes from the days when data was backed up on magnetic tapes. To create an archive of a directory, pass the cfz options to tar which will create a new archive in a file and then zip it in the gzip format.


$   tar cfz backupfile.tgz /var/www/vhosts/smashingmagazine.com/httpdocs
tar: Removing leading `/’ from member names

All Mac and Linux computers support the tar command and most also have zip. To do the same with zip:


$   zip -r backupfile.zip /directory/to/backup

To see what an archive contains, run:


tar tfz backupfile.tgz
var/www/vhosts/smashingmagazine.com/httpdocs/
var/www/vhosts/smashingmagazine.com/httpdocs/.htaccess...

Or for zip format:


unzip -l backupfile.zip
Archive:  test.zip
  Length      Date    Time    Name
---------  ---------- -----   ----
        0  2012-05-28 00:33   var/www/vhosts/smashingmagazine.com/httpdocs
      234  2012-05-28 00:33   var/www/vhosts/smashingmagazine.com/httpdocs/.htaccess...

Both tar and zip strip the leading slashes when they backup. So when you restore the files, they will be restored within the current directory. To restore them in the same location they were backed up from, first cd to /.


$   tar xfzv backupfile.tgz
var/www/vhosts/smashingmagazine.com/httpdocs/...

The “v” above stands for verbose and causes tar to show what it’s doing. zip has a similar option:


$   unzip -v backupfile.zip
Archive:  backupfile.zip
 Length   Method    Size  Cmpr    Date    Time   CRC-32   Name
--------  ------  ------- ---- ---------- ----- --------  ----
       0  Stored        0   0% 2012-05-28 00:33 00000000  var/www/vhosts/smashingmagazine.com/httpdocs/...

Website Errors

Let’s assume your website hasn’t actually disappeared. The next place to look is the error log file.

Finding the Log File

When using a server management package like Plesk, each website probably has its own log file. You can find it by grepping for the word “log” in the conf file you identified above. The -i means case-insensitive.


$   grep -i log /var/www/vhosts/smashingmagazine.com/conf/last_httpd.include
    CustomLog /var/www/vhosts/smashingmagazine.com/statistics/logs/access_log plesklog
    ErrorLog  “/var/www/vhosts/smashingmagazine.com/statistics/logs/error_log”...


There is also a server-wide log where any non-website-specific errors go. You can find this in the main conf file:


$   grep -i log /etc/apache2/apache2.conf
ErrorLog /var/log/apache2/error.log...

Htaccess Errors

It is very easy to screw up a website. You can quite readily bring down a very big website by removing a single character from the .htaccess file. Apache uses the file .htaccess to provide last-minute configuration options for a website. It is most often used for URL rewriting rules. They look like this:


RewriteRule   ^products/.*/([0-9]+)$     products/view.php?id=$  1   [L,QSA]

This rule says to rewrite any URL in the form “products/widget-3000/123” to the actual URL “products/view.php?id=123”. The L means that this is the last rule to be applied and QSAattach any query string to the new URL. URL rewriting is often used for search engine optimization so that Web managers can get the name of the product into the URL without actually having to create a directory called “widget-3000”.

However, make a single typo and your whole website will give a 500 Internal Server Error.

The tail command will display the last 10 lines of a log file. Give it a -1 to display the single last line instead. An .htaccess problem will look like this:


$   tail -1 /var/www/vhosts/smashingmagazine.com/statistics/logs/error_log
[Thu May 06 11:04:00 2013] [alert] [client 81.106.118.59] /var/www/vhosts/smashingmagazine.com/httpdocs/.htaccess: Invalid command ‘RewiteRule’, perhaps misspelled or defined by a module not included in the server configuration

You can grep for all of these types of errors:


$   grep alert /var/www/vhosts/smashingmagazine.com/statistics/logs/error_log
[Thu May 06 11:04:00 2013] [alert] [client 81.106.118.59]...

PHP Parse and Runtime Errors

Many websites use the LAMP combination: Linux, Apache, MySQL and PHP. A common reason for Web pages not showing up is that they contain a PHP error. Fortunately, these are quite easy to discover and pinpoint.

There are two broad classes of PHP errors: parse errors and runtime errors. Parse errors are syntax errors and include leaving off a semicolon or forgetting the $ in front of a variable name. Running errors include undefined functions or referencing objects which don’t exist.

Like .htaccess errors, parse errors will cause an HTML response code 500 for Internal Server Error, often with a completely blank HTML page. Runtime errors will give a successful HTML response of 200 and will show as much HTML as they have processed (and flushed) before the error happened. You can use telnet or wget -S or curl -i to get only the headers from a URL. So now, copy and paste your erroneous page into a command:


$   curl -i http://www.smashingmagazine.com/products/widget-3000/123
HTTP/1.0 500 Internal Server Error
Date: Sun, 12 May 2013 17:44:49 GMT
Server: Apache
Vary: Accept-Encoding
Content-Length: 0
Connection: close
Content-Type: text/html

PHP Error Settings

To find the exact error, you need to make sure errors are being reported in the log file.

There are several PHP settings which cover errors. display_errors determines if errors are shown to the website visitor or not, and log_errors says whether they will appear in log files. error_reporting specifies the types of errors that are reported: only fatal errors, for example, or warnings and notices as well. All of these can be set in a configuration file, in .htaccess or within the PHP script itself.

You can find out your current settings by running the PHP function phpinfo. Create a PHP file which calls the function and visit it in your browser:


$   echo “<?php phpinfo()?>” > /var/www/vhosts/smashingmagazine.com/httpdocs/phpinfo.php

phpinfo
phpinfo function showing configuration settings.

The two columns show the website and server-wide settings. This shows that display_errors is off, which is good, because it should be off on live websites. It means that no PHP errors will ever be seen by the casual visitor. log_errors on the other hand should be on. It is very handy for debugging PHP issues.

The error_reporting value is 30719. This number represents bit flags or bit fields. This is a technique for storing multiple yes/no values in a single number. In PHP there are a series of constants representing different types of errors. For example, the constant E_ERROR is for fatal errors and has the value 1; E_WARNING is for warnings and equals 2; E_PARSE is for parsing or syntax errors and has the value 4. These values are all powers of two and can be safely added together. So the number 7 means that all three types of errors should be reported, as E_ERROR + E_WARNING + E_PARSE = 7. A value of 5 will only report E_ERROR + E_PARSE.

In reality, there are 16 types of errors from 1 for E_ERROR to 16384 for E_USER_DEPRECATED. You can type “30719 in binary” into Google and it will give you the binary equivalent: 0b111011111111111. This means that all errors are switched on except the twelfth, which is E_STRICT. This particular setup has also been given a constant E_ALL = E_ERROR + E_WARNING + E_PARSE + etc = 30719. From PHP version 5.4.0, E_ALL is actually 32767 which includes all the errors include E_STRICT.

If your error_reporting setting is 0, then no errors will show up in the log file. You can change this setting in the file php.ini, but then you have to restart Apache to make it have an effect. An easier way to change this setting in Apache is to add a line in a file called .htaccess in your document root: php_value error_reporting 30719.

Or you can do that on the command line, using the double arrow which appends to an existing file or creates the file if it doesn’t exist:


$   echo “php_value error_reporting 30719” >> .htaccess
$   echo “php_value log_errors On” >> .htaccess

Refresh your erroneous Web page. If there is a PHP error in your page it should now show up in the error log. You can grep the log for all PHP errors:


grep PHP /var/www/vhosts/smashingmagazine.com/statistics/logs/error_log
[Sun May 12 18:19:09 2013] [error] [client 81.106.118.59] PHP Notice:  Undefined variable: total in /var/www/vhosts/smashingmagazine.com/httpdocs/products/view.php on line 10...

If you have referenced variables or array indices before assigning them values, you may see thousands of PHP notices like the one above. It happens when you do things like <? $ total = $ total + 1 ?> without initially setting $ total to 0. They are useful for finding potential bugs, but they are not show stoppers. Your website should work anyway.

You may have so many notices and warnings like this that the real errors get lost. You can change your error_reporting to 5 to only show E_ERROR and E_PARSE or you can grep specifically for those types of errors. It is very common to chain grep commands together like this when you want to filter by multiple things. The -e option below tells the second grep to use a regular expression. This command finds all log entries containing “PHP” and either “Parse” or “Fatal”.


$   grep PHP /var/www/vhosts/smashingmagazine.com/statistics/logs/error_log | grep -e “Parse|Fatal”
[Thu Jul 19 12:26:23 2012] [error] [client 81.106.118.59] PHP Fatal error:  Class ‘Product’ not found in /var/www/vhosts/smashingmagazine.com/httpdocs/library/class.product.php on line 698
[Sun May 12 18:16:21 2013] [error] [client 81.106.118.59] PHP Parse error:  syntax error, unexpected T_STRING in /var/www/vhosts/smashingmagazine.com/httpdocs/products/view.php on line 100...

Seeing Errors in the Browser

If you are tracing a runtime error rather than a parse error, you can also change the error_reporting setting directly in PHP. And you can quickly turn display_errors on, so you will see the error directly in your browser. This makes debugging quicker, but means everyone else can see the error too. Add this line to the top of your PHP page:


<? ini_set (’display_errors’, 1); error_reporting (E_ERROR | E_WARNING); ?>

These two functions change the two PHP settings. The | in the error_reporting call is a bit OR operator. It effectively does the same as the + above but operates on bits, so is the correct operator to use with bit flags.

Any fatal errors or warnings later in the PHP page will now be shown directly in the browser. This technique won’t work for parse errors as none of the page will run if there’s a parse error.

Bit Flags

Using bit flags for error_reporting avoids having 15 separate arguments to the function for each type of error. Bit flags can also be useful in your own code. To use them, you need to define some constants, use the bit OR operator | when calling the function and the bit AND operator & within the function.

Here’s a simple PHP example using bit flags to tell a function called showproduct which product properties to display:


<?
define (’PRODUCT_NAME’, 1);
define (’PRODUCT_PRICE’, 2);
function showproduct ($  product, $  flags) {
  if ($  flags & PRODUCT_NAME) echo $  product[’name’];
  if ($  flags & PRODUCT_PRICE) echo ‘: $  ’ . $  product[’price’];
}
$  product = array (’name’=>’Widget 3000’, ‘price’=>10);
showproduct ($  product, PRODUCT_NAME | PRODUCT_PRICE);
?>

This will display “Widget 3000: $ 10” in the browser.

Infinite Loops

PHP’s error reporting may struggle with one class of error: an infinite loop. A loop may just keep executing until it hits PHP’s time limit, which is usually 30 seconds (PHP’s max_execution_time setting), causing a fatal error. Or if the loop allocates new variables or calls functions, it may keep going until PHP runs out of workable memory (PHP’s memory_limit setting).

It may, however, cause the Apache child process to crash, which means nothing will get reported, and you’ll just see a blank or partial page. This type of error is increasingly rare, as PHP and Apache are now very mature and can detect and handle runaway problems like this. But if you are about to bang your head against the wall in frustration because none of the above has worked, then give it some consideration. Deep within your code, you may have a function which calls some other function, which calls the original function in an infinite recursion.

Debuggers

If you’ve gotten this far, and your page is still not showing up, then you’re entering more difficult territory. Your PHP may be executing validly and doing everything it should, but there’s some logical error in your programming. For quick debugging you can var_dump variables to the browser, perhaps wrapping them in an if statement so that only your IP address sees them:


<? if ($  _SERVER[’REMOTE_ADDR’] == ‘85.106.118.199’) var_dump ($  product); ?>

This method will narrow down an error but it is ungraceful and error-prone, so you might consider a debugging tool such as Xdebug or FirePHP. They can provide masses of information, and can also run invisibly to the user, saving their output to a log file. Xdebug can be used like this:


<?
ini_set (’xdebug.collect_params’, 1);
xdebug_start_trace (’/tmp/xdebugtrace’);
echo “This will get traced.”;
xdebug_stop_trace();
?>

This bit of code logs all function calls and arguments to the file /tmp/xdebugtrace.txt. It displays even more information when there is a PHP notice or error. However, the overhead may not be suitable for a live environment, and it needs to be installed on the server, so it’s probably not available in most hosting environments.

FirePHP, on the other hand, is a PHP library that interacts with an add-on to Firebug, a plugin for Firefox. You can output debugging information and stack traces from PHP to the Firebug console.

Security Issues

By this point, you should have some HTML reaching your browser. If it’s not what you expect, then there’s a chance that your website has been compromised. Don’t take it personally (at first). There are many types of hacks and most of them are automated. Someone clever but unscrupulous has written a program which detects vulnerabilities and exploits them. The purpose of the exploit may simply be to send spam, or to use your server as part of a larger attack on a more specific target (a DDoS).

Server Hacks

Operating systems are very complex pieces of software. They may be built from millions of lines of programming code. They are quite likely to have loopholes where sending the wrong message at just the wrong time will cause some kind of blip which allows someone or something to gain entry. That’s why Microsoft, Apple, Ubuntu and others are constantly releasing updates.

Similarly, Apache, nginx, IIS and all the other software on a typical server is complicated. The best thing you can do is keep it up to date with the latest patches. Most good hosts will do this for you.

A hacker can use these flaws to log in to your server and engineer themselves a terminal session. They may initially gain access as an unprivileged user and then try a further hack to become the root user. You should make this as hard as possible by using good passwords, restrictive permissions, and being careful to run software (like Apache) as an unprivileged user.

If someone does gain access, they may leave behind a bit of software which they can later use to take control of your server. This may be detectable by an antivirus scanner or something like the Rootkit Hunter, which looks for anomalies like unexpected hidden files. But there are also a few things you can do if you suspect an intrusion.

The w command shows who is currently logged in to a server and what they are doing:


$   w
 20:44:32 up 44 days,  7:51,  2 users,  load average: 0.07, 0.03, 0.05
USER     TTY      FROM              LOGIN@   IDLE   JCPU   PCPU WHAT
root     pts/0    cpc1-brig17-2-0- 17:54    1:02m  0.15s  0.13s -bash
root     pts/1    cpc1-brig17-2-0- 20:44    0.00s  0.02s  0.00s w...

The last command shows who has logged in recently in date order. Pipe it through head to show only the first 10 lines.


$   last
paul     pts/0        :0.0             Sun May 12 17:21   still logged in
paul     tty7         :0               Sun May 12 17:20   still logged in
reboot   system boot  2.6.32-41-386    Sun May 12 17:18 - 20:48  (03:29)
fred     tty7         :0               Sat May 11 10:10 - down   (01:12)...



It tells you who has logged in and for how long, plus any terminal session they have open. down means until the server shut down. Look for unexpected entries and consult your host or a security expert if you are in doubt.

PHP Hacks

More common are hackers who gain entry though vulnerabilities in PHP scripts, especially popular content management systems like WordPress. Anybody can write a plugin for WordPress and, if it’s useful, people will install it. When writing a plugin, most developers think primarily about the functionality and little about security. And because WordPress allows file uploading, hackers who find vulnerabilities can use them to upload their own PHP scripts and later take control of a computer.

These PHP scripts can use the PHP mail function to send out spam on demand, but they can also try to execute commands in much the same way as you can via a terminal session. PHP can execute commands with its exec or system functions. If you do not need to use these functions, it is advisable to disable them. You can do this by adding the disable_functions directive to your server’s php.ini file (or php5.ini for PHP 5) or to the file php.ini within your document root. If you search for “php disable functions” in Google, you will find a whole list of functions which should be disabled in this way:


disable_functions=fpassthru,crack_check,crack_close...

A quick check you can make for this type of hack is to look for all PHP files modified recently and make sure there are no anomalies. The -mtime -1 option tells find to only consider files modified within the last day. There’s also -mmin for minutes. This command searches all websites within /var/www/vhosts for recently modified files ending in “php” or “inc”:


$   find /var/www/vhosts -mtime -1 ( -name *php -o -name *inc ) -printf “%t %h/%fn”
Sun May 12 21:20:17.0000000000 2013 /var/www/vhosts/smashingmagazine.com/httpdocs/products/view.php



PHP hacks are difficult to detect because they are designed to not stick out. One method hackers use is to gzip their PHP and then encode it as base64. In that case, you may have a PHP file on your system with something like this in it:


eval(gzinflate(base64_decode(’HJ3HkqNQEkU/ZzqCBd4t8V4YAQI2E3jvPV8...




Another method is to encode text within variables and then combine them and evaluate them:


$  unywlbxc = “ uwzsebpgi840hk2a jf”;
$  hivjytmne = “  jqs9m4y 1znp0  “;
eval ( “m”.”i”. “croti”...



Both these methods use the PHP eval function, so you can use grep to look for eval. Using a regular expression with bevalb means that the word “eval” must have a word boundary before and after it, which prevents it being found in the middle of words. You can combine this with the find command above and pipe through less for easy reading:


$   find /var/www/vhosts -mtime -1 ( -name *php -o -name *inc ) | sed ‘s/ / /g’ | xargs grep -H -e “bevalb” | less
/var/www/vhosts/config.php:eval(gzinflate(base64_decode(’HJ3HkqNQE...




If you do find this type of hack in your website, try to discover how they got in before completely removing all the tainted files.

Access Logs

Along with error logs, Apache also keeps access logs. You can browse these for suspicious activity. For example, if you found a PHP hack inside an innocuous looking file called test.php, you can look for all activity related to that file. The access log usually sits alongside the error log and is specified with the CustomLog directive in Apache configuration files. It contains the IP address, date and file requested. Search through it with grep:


$   grep -e “(GET|POST) /test.php” /var/www/vhosts/smashingmagazine.com/statistics/logs/error_log
70.1.5.12 - - [12/May/2013:20:10:49 +0100] “GET /test.php HTTP/1.1” 200 1707 “-” “Mozilla/5.0 (X11; Ubuntu; Linux i686;...

This looks for GET and POST requests for the file test.php. It provides you with an IP address, so you can now look for all other access by this address, and also look for a specific date:


$   grep 70.1.5.12 /var/www/vhosts/smashingmagazine.com/statistics/logs/error_log | grep “12/May/2013”
70.1.5.12 - - [12/May/2013:20:10:49 +0100] “GET /products/view.php?something HTTP/1.1” 200 1707 “-”...
70.1.5.12 - - [12/May/2013:20:10:49 +0100] “GET /test.php HTTP/1.1” 200 1707 “-” “Mozilla/5.0 (X11; Ubuntu; Linux i686;...

This kind of debugging can be very useful for normal website errors too. If you have a feedback form on your website, add the user’s IP address to the message. If someone reports an error, you can later look through the logs to see what they have been up to. This is far better than relying on vague second-hand information about reported problems.

It can also be useful for detecting SQL injection attacks, whereby hackers try to extract details from your database by fooling your database retrieval functions. This often involves a lot of trial and error. You could send yourself an email whenever a database query goes wrong and include the user’s IP address. You can then cross-reference with the logs to see what else they have tried.

Last Resorts

William Edward Hickson is credited with popularizing the saying:

“If at first you don’t succeed, try, try, try again.”

Hickson was a British educational writer living in early Victorian times. His advice is not appropriate for the modern Web developer, lying in bed on a Saturday morning, drowning in frustration, staring at a blank Web page, preparing to chuck an expensive laptop against a brick wall.

You’ve now been through all the advice above. You’ve checked that the world hasn’t ended, verified your broadband box, tested the Internet and reached your server. You’ve looked for hardware problems and software problems, and delved into the PHP code. But somehow or other, your Widget 3000 is still not there. The next thing to do is…

Have Breakfast

Get out of bed and take your mind off the problem for a little while. Have some toast, a bowl of cereal, something to drink. Maybe even indulge in a shower. Try that new lavender and citrus shampoo you bought by mistake. While you’re doing all this, your subconscious is busily working on the website issue, and may unexpectedly pop a solution into your thoughts. If so, give it a try. If not…

Ask for Help

Check the level of support that you are entitled to by your hosting company. If you are paying $ 10 per month, it’s probably not much. You may be able to get them to cast a vague glance in your direction within the next 72 hours. If it’s substantially more, they may log in and have a look within the next few minutes. They should be able to help with hardware or software issues. They won’t help with Web programming issues. Alternatively, ring a colleague or freelancer. If you are still stuck…

Prepare

…to release some nervous energy. Find one of those squidgy balls that you can squeeze mercilessly in your hands, or a couple pencils to use as drumsticks, or a pack of cigarettes and a pot full of coffee. And then try the last resort to any computing problem…

Reboot

When your laptop or desktop goes wrong, a common solution is to reboot it. You can try the same trick on your Web server. This is a quite risky. Firstly, it may not solve the problem. If it’s a PHP error, then nothing will change. If, however, your issue is caused by some obscure piece of software becoming unresponsive, then it may well help, though it may not fix the problem permanently. The same thing may happen next week.

Secondly, if the reboot fails then you will be really stuck. If the server shuts down but fails to start back up again, then someone may have to go and press the power button on the physical machine. That someone is an employee of your hosting company, and they may be enjoying their breakfast too, in a nice comfortable office somewhere. They may have left their jumper at home. They may not want to enter the air-conditioned bunker where all the servers are kept. You will be thoroughly dependent on their response time.

Given all the risks, the command is:


$   sudo /sbin/reboot
Broadcast message from admin@thisserver.com (/dev/pts/1) at 13:21 ...
The system is going down for reboot now.

The reboot command is really just a wrapper for /sbin/shutdown -r now. It causes the server to shut down and then restart. That may take a few minutes. Soon after issuing the command above your SSH session will come to an abrupt end. You will then be left for a few nervous minutes wondering if it will come back up again. Use the tools you prepared above.

While you are waiting, you can issue a ping to see if and when your server comes back. On Windows use ping -t for an indefinite ping:


$   ping www.smashingmagazine.com
PING www.smashingmagazine.com (80.72.139.101) 56(84) bytes of data.
Request timeout for icmp_seq 0
Request timeout for icmp_seq 0
Request timeout for icmp_seq 0...
64 bytes from www.smashingmagazine.com (80.72.139.101): icmp_seq=1 ttl=52 time=39.4 ms
64 bytes from www.smashingmagazine.com (80.72.139.101): icmp_seq=1 ttl=52 time=32.4 ms...

You can breathe a sigh of relief when ping finally responds. Wait a couple more minutes and you’ll be able to use ssh again and then try to view the Widget 3000 in your Web browser.

Conclusion

This has been an epic journey, from the end of the world to a single misplaced character in a file. Hopefully, it will help you through the initial few minutes of panic when you wake up one morning and the beautiful product page you created last night is gone.

Some of the reasons and solutions above are very rare. The most likely cause is simply a slight malfunction in your broadband box. Running out of disk space or getting hacked are the only other things that are in any way likely to happen in the middle of the night when nobody else is working on the website. But throw in other developers, server administrators and enthusiastic clients — and anything is possible. Good luck!

Footnotes

1. Oxford Dictionary of Quotations (3rd edition), Oxford University Press, 1979

Paul Tero’s chapter has been reviewed by Ben Dowling and Sergey Chikuyonok.

Pre-Order Your Copy Today!

New Perspectives on Coding

We hope you’ve enjoyed this sample chapter of the Smashing Book #4! We would sincerely appreciate your support with an occasional tweet, Facebook post or Google+ update, or just a word to your friends and colleagues! You can also learn more about the Smashing Book #4 first. Again, thank you for all your support!

(og) (il) (vf) (ea) (cm)

Desktop Wallpaper Calendar: August 2013


  

We always try our best to challenge your artistic abilities and produce some interesting, beautiful and creative artwork. And as designers we usually turn to different sources of inspiration. As a matter of fact, we’ve discovered the best one—desktop wallpapers that are a little more distinctive than the usual crowd.

This creativity mission has been going on for over five years now, and we are very thankful to all the designers who have contributed and are still diligently contributing each month. This post features free desktop wallpapers created by artists across the globe for August 2013. Both versions with a calendar and without a calendar can be downloaded for free. It’s time to freshen up your wallpaper!

Please note that:

  • All images can be clicked on and lead to the preview of the wallpaper,
  • You can feature your work in our magazine by taking part in our Desktop Wallpaper Calendar series. We are regularly looking for creative designers and artists to be featured on Smashing Magazine. Are you one of them?

Agosto Ketchup

“A calendar inspired by Heinz Ketchup. A big honor to Mr. Heinz, who made one of the famous ketchup brands in the world. This is for the ketchup lovers (including me!).” Designed by Pat Buenaobra from the Philippines.

Agosto ketchup

I Love Summer

“I love summer :)” Designed by Vector4free from Poland.

I love summer

Leo

“I’m always interested in learning more about the zodiac signs. July 23- August 23 is the time of the Lion, Leo. I based my wallpaper design around this and included the constellation of Leo as well. Enjoy!” Designed by Franny Van Eyck from Wisconsin, USA.

Leo

Poppy Herbarium

“Summer is taking off with some magical ice cream hot air balloons.” Designed by Sasha Endoh from Canada.

Poppy herbarium

Hanabi Festival

“From late July to early August, Japanese will celebrate summer with hanabi (fireworks) throughout Japan!” Designed by Evangeline Neo from Japan.

Hanabi Festival

World Alpinism Day

“International Day of Alpinism and Climbing.” Designed by cheloveche.ru from Russia.

World Alpinism Day

Johnny Depp

“Instead of using normal lines and shades to sketch the portrait, I’d first break it up into small triangles. Then I’ll (slowly and painstakingly) fill the triangles up with different shades of black using different shades of pencils, and viola, the portrait is done! Hope you guys like it!” Designed by Teo Yu Sheng from Singapore.

Johnny Depp

Handwritten August

“I love typograhy handwritten style.” Designed by Chalermkiat Oncharoen from Thailand.

Handwritten August

World Photography Day!

“In August we have the world photography day. So it is fair to make this homage to those that translates and makes us immortalize the most special moments of our lives.” Designed by ADD from Brazil.

World Photography Day!

The Balinese Flower

Designed by Nitesh Bhatia from India.

The Balinese Flower

Autumn Is Just Around the Corner

“August is the month that brings to mind the passage of summer season and the arrival of autumn. The entire landscape around us gets a new look, and each of us remains nostalgic due to the passage of summer.” Designed by Tattoo Temptation from United Kingdom.

Autumn is Just Around the Corner

Estonian Summer Sun

“This is a moment from Southern Estonia that shows amazing summer nights.” Designed by Erkki Pung / Sviiter from Estonia.

Estonian Summer Sun

Woof!

Designed by Laurent Constant from Belgium.

Woof!

Solidarity

“Black and white landscape/waterscape photo.” Designed by Jeremy Mullens from United States.

Solidarity

Summer Holidays

“A colorful wallpaper for the month of holidays! Have a great summer holiday!” Designed by Laboratorio Creativo from Romania.

Summer holidays

That Is Rain To Me!

Designed by Dhwani Gandhi from India.

That is rain to me!

The Great British Summer

“With Britain currently basking in a sub-tropical heatwave, sporting success and the birth of the Royal baby, we felt it appropriate to celebrate all the things we love about the Great British summer in the form of a wallpaper. Perfect for proud Britons and Britophiles alike!” Designed by Fluid Creativity from Manchester, United Kingdom.

The Great British Summer

Monsoon Sale!

“Hey monsoon is here! So grab your umbrella in this monsoon sale, and don’t miss the fun in the rain.” Designed by Debobrata Debnath from India.

Monsoon sale!

Flowing Creativity

Designed by Creacill, Carole Meyer from Luxembourg.

Flowing creativity

Off To The Beach We Go

“’Off to the beach we go’ is based on screenshots from my latest browser game (I’m an indie games designer).” Designed by Bart Bonte from Belgium.

off to the beach we go

Join In Next Month!

Please note that we respect and carefully consider the ideas and motivation behind each and every artist’s work. This is why we give all artists the full freedom to explore their creativity and express emotions and experience throughout their works. This is also why the themes of the wallpapers weren’t anyhow influenced by us, but rather designed from scratch by the artists themselves.

A big thank you to all the designers for their participation. Join in next month!

What’s Your Favorite?

What’s your favorite theme or wallpaper for this month? Please let us know in the comment section below.


© The Smashing Editorial for Smashing Magazine, 2013.

Smashing Magazine Feed

The “Other” Interface: Atomic Design With Sass


  

As front-end developers and designers, we’re constantly refining two interfaces simultaneously: one for visitors who load the website, the other for developers who have to tackle the code in the future, when adjustments or full-scale redesigns must be made. Yet we tend to assign the role of “user” to the first group, often forgetting that the code we write must work for developers in a similar way. We shouldn’t forget that developers are users, too.

If this is the case, then our convention for naming and organizing files is critical if we are to ensure active (and efficient) development in the future. But do we really design the partials, files and directories that make up this interface with a particular set of users in mind, with a set of clear goals, combined with precise, well-defined documentation? I don’t think we do.

Recently, I’ve been working on many different projects, each wildly different from each other. And the various problems I’ve faced while switching between the projects has made me wonder how we can drastically improve front-end accessibility.

We Need To Follow Atomic Design Principles In Our Style Sheets

Last month, in a post titled “Atomic Design,” Brad Frost argued that Web development could be improved. He suggested to developers that, instead of coding a form as a component that is reused throughout a website, they could style small modules — such as a placeholder, input field and text field — and then create each form by combining these chunks together. This process could be duplicated for navigational items, text with icons, floated objects and pretty much any other sort of front-end module that needs to be reused regularly.

atoms-500_mini
(Image: Brad Frost)

“Atomic design gives us the ability to traverse from abstract to concrete. Because of this, we can create systems that promote consistency and scalability while simultaneously showing things in their final context. And by assembling rather than deconstructing, we’re crafting a system right out of the gate instead of cherry picking patterns after the fact.”

The theory is that by employing these distinct elements, a developer can speed up their workflow and write code more efficiently because they’re not forced to repeat themselves. This much appears to be common sense. Essentially, what Brad calls for is object-oriented design, which has been discussed in numerous articles and blog posts recently. That isn’t really what interested me about the idea, though — it was the naming convention that Brad chose.

He uses scientific terms to quickly describe what sections of a design should do; “atoms” are the discrete chunks (placeholders, labels, etc.), while “molecules” are combinations of these standard atoms. The simplicity here grabbed my attention, because ultimately what we’re discussing isn’t just a process for design, but also a distinction to be made in the user interface, as I mentioned earlier.

Problems With The Front-End Interface

Before we retroactively squeeze some of Brad’s ideas into our current workflow, we have to figure out precisely which problems need to be solved. So, as I switched between my projects, I started to take note of the flaws that appeared to be wasting much of my time. By the end, I counted three main problems that affect the developer’s workflow:

1. Finding Code Should Be Easy

Although I had written some components with Sass early on in a project, I found that towards the end, I was simply incapable of remembering where in the stack I needed to make adjustments. This forced me to try to memorize where each block of code was and had me scurrying around, completely lost, even with the advanced search features of a great text editor.

Developers are probably quite familiar with Sass files, which contain thousands of lines of code. The legacy Ultimate Package, a tool that we used as a boilerplate for all of our front-end code at Erskine, also contained that unfortunate mistake. The main problem with keeping all of this code in one place and not breaking the files into smaller parts is that you’re likely to forget where a particular section of code is. This eventually wastes the developer’s time and could slow down the project considerably.

Of course, these problems become infinitely worse when you must navigate someone else’s project or an entirely unfamiliar code base.

2. Figuring Out the Relationships Between Modules Should Be Straightforward

Whenever I try to add a component to an old website, I have to figure out the mental model of the relationships between elements. I have to wonder how removing a portion of the website would affect another totally unrelated thing elsewhere. This could be a background color or margins or padding or even the order of elements in a module (such as an image in a comments section combined with text from the same object).

Nicole Sullivan mentions in her fantastic talk at Webstock that these elements can become so interwoven with one another that they pose hurdles down the road. This problem often forces me to move from the text editor to the Web inspector and manipulate elements by hand in order to get an idea of how things work together, and then move back to the editor to make the fix.

This is unnecessarily slow and cumbersome. With atomic design, we would know precisely how one element affects another; we wouldn’t have to worry about editing components, or even adding new ones.

3. Websites Need Tailor-Made Components

Sometimes a design requires a component that is never reused, a sort of one-of-a-kind embellishment that sparks interest or delight in the user in some way. If it were repeated, it would become boring or, worse, repellant. Ideally, a new organizational system would allow for the sort of design components that Allen Tan describes in his article “Made to Measure”:

“Design is about establishing a set of relationships between elements. By codifying these relationships as a set of principles instead of a single, stand-alone template, we make it possible for other designers to extend our work (per article) while remaining faithful to its core ideas.”

Yet we know that these minute design variations can quickly turn into a royal pain. Having to maintain all of these various fluctuations of commonly used structures would turn most projects into very hostile coding environments.

Of course, if we used some of this atomic design thinking, we wouldn’t have to worry about unnecessary code bloat when we add a fancy banner or an alternative text style to a figure. Hopefully, it would encourage us to scope components of the code base so that another user could easily identify which objects are global and which are specific to a single template or module.

What we need to do here is group components according to the sort of effect they might have on the entire system. Atomic design to the rescue!

The System

Last month, I stumbled upon the wonderful Inuit.css framework, which is probably the best place to start learning if you’re unfamiliar with modular design in Sass. After a few moments of playing around, I saw that this is a phenomenal step forward for developers and designers alike. It employs BEM’s syntax, object-oriented CSS (OOCSS) and many aspects of atomic design, which all might seem a little overwhelming at first but is definitely worth going through because you’ll likely see the advantages soon enough.

The problem I had with Inuit.css was with its naming conventions. What was contained in the base, generic and object directories wasn’t entirely obvious. These relationships should be obvious and immediate; developers shouldn’t have to read hundreds of lines of code and tediously experiment in order to be able to fix a bug or add a feature.

So, I decided to fork my own version and combine these atomic design ideas with the principles of BEM and OOCSS from Inuit. I’ll describe this alternative convention here. Now that we’ve discussed some of the key problems, we can look at how atomic design can help us.

The Control Panel

First, it’s worth mentioning that we’ll have a style sheet that imports all of the Sass partials we’re about to make. Think of this as our control panel, because in the future we won’t want to write all of our code from scratch; for most projects, we’ll just want to set things up quickly and turn an object on or off. All of the partials will be compiled to this file before we convert it to plain old CSS and serve it up to our website. So far, so good.

Utilities

Atomic design encourages us to first think as vaguely as possible, and then to focus our energy on the smallest pieces later. This means that we need a set of system-wide styles to begin; this directory of Sass files will need to define the foundation; effectively, what’s required is a set of utilities that make up the basic plumbing of the website. This directory of partials is also important because we’ll need to define global classes, mixins and styles that can be used anywhere and at any time. Our utilities directory might look something like this:

Breakdown of the files within the utilities directory: base-spacing.scss, cleafix.scss, reset.scss

The code in our reset, clearfix and base-spacing partials have a global impact, changing almost every page, template, element and module. By scoping our code in this way, we can easily find these partials later and hide them when our focus is needed elsewhere.

Quarks

Next up, we ought to define the basic building blocks of the website, including paragraphs, tables, images and links. Be careful here: We need to slowly build up to the complexity that is required so that we don’t step on our own toes later. At this stage, we should still be thinking globally and not styling for any particular section of the design.

Therefore, this next directory should focus only on default HTML elements. I’ve started to call these components quarks — classless objects that, within the files themselves, contain nothing more than a few elements:

Breakdown of the quarks directory: lists.scss, paragraphs.scss etc.

Note that these files contain only the default styles for these elements, not modified elements. For example, if we have a table that looks and works entirely differently from the default tables used throughout the website, it would not be a quark.

This system might look like overkill at this point. Why do we need a separate partial to style almost every default element individually? My argument is that if we were to combine all of these small pieces together, we would make the files less readable, especially on a large website. Having a substantial number of partials is fine, as long as they’re easy to find and organized properly.

Quarks are also helpful when we set up a style guide or an elements template page that lists the various default components of a project.

Atoms

Now we need to start thinking about the relationships between these quarks, and so we start to introduce aspects of BEM and OOCSS. In this system, I’ve called these modules “atoms” — universal abstractions, such as the media or flag object. For example, we might include a partial that sets the default style for buttons, so that we can plan for those styles to be extended and built upon:

Breakdown of the atoms directory: media.scss, buttons.scss etc.

The styles in an atom should almost never be attached to an HTML element itself; we might not be able to guarantee what the markup will look like in the future. Specifying a class instead is always safer.

In this way, atoms will save us from writing hundreds of lines of code and keep things relatively abstract. Just as Brad suggests, this concept is powerful because atoms can be combined to form more complicated structures.

Molecules

As I mentioned earlier, sometimes we need one-off structures, such as a banner or navigation element or footer, that we don’t intend to replicate. This is where we can combine multiple quarks and atoms, without interfering with any of our global styles:

Examples of files from the molecule directory: banner.scss, footer-nav.scss

A molecule can take advantage of an atom for layout (such as the heading-group molecule, which might manipulate the styles of the heading quark, which lists the styles for h1, h2 etc.). But then, within this molecule, we can extend, modify and combine other styles and modules.

So, while atoms and quarks define rigid and clear rules for the system overall, and utilities provide the outlining structural styles necessary to keep things tidy, the molecules are where the design can be more flexible and extend styles out from those central tenets of the system.

As you can see, quarks, atoms and molecules break up those monster Sass files that I mentioned earlier and make code faster to read and easier to maintain in the long run.

We Need To Revise Our Current Best Practices

Although the system outlined here is pretty rigid, these are not die-hard rules. This is not the only way to organize styles with Sass, and I’m not arguing that it’s a panacea for our front-end woes. I’m simply proposing that we take a good look at the developer interface and try to make things better for everyone.

This system could even be based on another kind of taxonomy or categorization, completely unrelated to biology or chemistry. But, as you can see, this is more than just a goofy way to name files and directories — rather, it suggests the kinds of relationships between these independent components. Thanks to this system, our code should be much faster to read and organize and, alongside detailed instructions and documentation, enable another Web developer to be up and running in minutes.

In the past, directories and file names were often poorly designed navigational tools. But if we think long enough about the other interface (the one for developers) and about alternative frameworks and helpful tools to make our code base more human-readable, then we can finally put some of these problems to rest and worry about other more elusive issues.

Relevant Talks

(al) (ea)


© Robin Rendle for Smashing Magazine, 2013.

Smashing Magazine Feed

Teaching Web Design To New Students In Higher Education

The Web is evolving rapidly. Front-end Web development has been majorly affected by recent changes in coding techniques and approaches. In 2003, a competent front-end Web developer would have known HTML and CSS, possibly with a bit of copy-and-pasted JavaScript, and they built websites that would be viewed on desktop computers.

Not so in 2013! Now, a competent front-end Web developer is well-versed in HTML and CSS, JavaScript and jQuery, CSS preprocessors, new techniques such as responsive design and mobile first, and a world of new devices for viewing websites.

Just as a front-end Web developer’s job has changed, so must the basic introductory Web design classes offered all over higher education. How should one teach students who know nothing about HTML or CSS, so that they think about designing and building websites in a device-independent manner, using modern techniques such as responsive design and mobile first?

I have been teaching introductory Web design for 13 years in a variety of academic and commercial settings, and I’ve given a lot of thought to how we should be teaching two of the earliest and most basic courses in a college Web design and development curriculum. This discussion is important, because only a few resources are available for teaching Web design and development. Due to a lack of time and the rapid evolution of the Web, it’s difficult to revisit courses and update them with the latest material every year.


Increasing collaboration between full-time professors and part-time adjuncts can help improve the student experience. Image source

Adjunct instructors, who frequently teach part-time and typically hold a “day job,” often build websites professionally and have resources to keep up with the latest trends and techniques in the field. However, without easy access to great teaching resources, they may find it difficult to present this cutting-edge material in a way that students can understand and appreciate. Full-time instructors and professors typically don’t build websites professionally (or they’ll build few of them), and with many other demands on their time, they may have a hard time keeping up with trends and techniques.

However, they often have deep experience in teaching methodologies, with a clear sense of what works and what doesn’t in Web design education. Because many adjunct instructors teach evenings and weekends, whereas full-time instructors usually teach day classes, these faculty rarely interact. Part of the key to improving the student experience, quality of teaching and curricula is to increase collaboration between full-time professors and part-time adjuncts. Both groups of instructors bring valuable and complementary skills to higher education. (Low salaries for adjunct instructors are also important to the discussion but, unfortunately, beyond the scope of this article.)

In this article, I’ll focus on just two courses: an introductory graphic design course and an introductory HTML and CSS course. Concepts such as website strategy and planning, mobile first, information architecture, usability, user-centered design, JavaScript and jQuery, content management systems and so forth are valuable and should be covered in the curriculum. However, these topics are typically (or at least should be) covered in separate courses in most college curricula and, so, are not addressed here.

Creating Designs

In most college Web design programs, students will take a course on creating website layouts as a single graphic in software such as Photoshop or Fireworks. Students might start with a screenshot of an existing website, layering on their own images and content to create a unique design, or they might create a design from scratch.

The idea behind this class is sound. Once students have mastered the basics of working with the software, the course generates discussion of usability, color, layout, fonts, negative space, image quality and placement and so much more, all without involving code. It enables students to picture a Web page in their minds without being too concerned about how the page would be coded. When the student does start coding the page, they will have the skills to clarify what they want to build before writing a line of code.


It is important to let students form an idea of a Web page before involving code. Image source

In this course, students frequently have trouble understanding what happens beyond the canvas. If the design is 960 pixels wide, what happens when the monitor is 1200 pixels wide? Usually that’s addressed by a background color or repeated graphic. Students are rarely asked what happens if the monitor is narrower than 960 pixels.

Most students, if asked about a narrower window, would point out the scroll bar across the bottom of the page, alerting the visitor to expand their browser to see the full design. They don’t consider whether buttons are too close together for touch-based navigation, for example, or how text size might vary at different screen dimensions. Students in this course can, however, be guided to think about these issues.

Many design studios that focus on responsive design do not use comps, like those generated in this class, as part of their development process anymore. Instead, they prefer to use HTML and CSS-based comps to demonstrate the look of a website to a client. So, why teach image-based comps to students?

The reason is that, at this point in their development, students don’t necessarily know HTML and CSS well, if at all. By removing code from the picture, students focus on design principles, including graphic design and user experience. Once they learn HTML and CSS, they might never create an image-based comp again. However, in this process, they have learned how to navigate Photoshop and/or Fireworks, and they’ve learned the positives and negatives of working in a comp environment — all of which are valuable experiences.

Here are some tasks you could assign to improve this class and to prepare students for device-independent design work:

  • Build a design in 12 evenly-sized columns.
    This is a great time to explain about grids and how they work. Have students build designs based on this grid to demonstrate their understanding.
  • Show versions of the design.
    If the design looks one way at 960 pixels, how does it look at 1200 pixels? 320? 767? Have students use the same content in their designs, rearranged for these different screen environments. Be sure to ask about transitions — what happens as the design moves from 767 to 320 pixels?
  • Ask questions about photos.
    What does that big photo banner stretching so beautifully across the top of the page at 960 pixels look like at 767 pixels? What happens between 960 and 767 pixels?
  • Encourage students to think about touch.
    This is particularly important at smaller screen dimensions, but desktops and laptops are trending towards touch as well. Encourage students to build navigation suitable for fat fingers, for example.
  • Deemphasize slicing.
    Rather than thinking about the comp as the source of imagery for a website, consider it its own prototype. Slicing may not be required at all, because images may need to be generated in several sizes for different screen dimensions. Even background graphics can be generated in their own independent documents. By deemphasizing slicing, you also deemphasize the centrality of this comp for the website’s design. With responsive design, the comp sets a goal or a direction, but tweaking is required to accomodate the space between 320, 767 and 960 pixels and beyond.

Note that some companies are working on the problem of designing in a flexible environment without using code. When these programs are more stable, they might be worth incorporating into the college curriculum.

Teaching HTML And CSS

In a typical HTML and CSS course, students learn the difference between markup and presentation. Over the course of the term, students learn to create a Web page from scratch, manipulating HTML, CSS and image files. Their layouts will usually be completely custom, and they will typically learn about floats and positioning as part of this process. Browser compatibility may be touched upon as it is encountered.


“Don’t Fear The Internet” is a fantastic learning resource that teaches some quite useful HTML and CSS basics.

Fundamentally, nothing is wrong with this class. Students will leave knowing how to hand-code standards-compliant HTML and CSS. However, it does need a few modifications to account for modern design techniques:

  • Standardize in one browser.
    I’d recommend working with Firefox or Chrome as the standard browser in class, because they’re available on Mac and PC and are the most standards-compliant. Tell students that this is the only browser that matters for the purpose of this class. Cross-browser issues should be dealt with later, once students understand how HTML and CSS work completely in this browser. When cross-browser problems are introduced too soon, students get confused, unclear whether a particular problem is due to the browser or just badly formed code.
  • Teach HTML5.
    Students should learn how to mark up documents with sections, asides, navigation, headers and footers from the start.
  • Teach CSS3 and all types of selectors.
    Make sure students understand media queries as soon as they are able to. Introduce adjacent sibling selectors, child selectors, universal selectors, various pseudo-classes and so forth. Again, worry less about browser support, because these students have years before graduation.
  • Incorporate grid-based thinking early on.
    Even if students can’t code their own grid yet, they could certainly build layouts while thinking about 12 columns, using em and/or percentage widths and sizes. Have students code standard shapes of pages, such as two- and three-column layouts, with or without headers, footers and horizontal navigation, rather than leaving students open to code any type of layout. Understanding the trade-offs between design and code is important, so always address those.
  • As soon as students grasp floats and positioning, teach how to code a grid.
    Because students have been thinking about Web design with grid-based principles, this transition should be fairly quick for them.
  • Responsive design is now a short lecture, not a long one.
    Students are now able to pull together grid-based layouts and media queries. They’ve likely encountered image-resizing issues along the way, but if not, this is the time to discuss them.
  • Now is the time to discuss browser compatibility.
    Now that students have mastered valid, standards-compliant, responsive code, it’s time to think about browser compatibility. One way to introduce this is to work with poorly supported HTML5 tags or CSS3 elements such as rounded corners.
  • CSS preprocessing is a hot topic.
    Centralizing CSS variables is a great idea and is bound to be a core CSS skill, required by employers, in the next year or two. (Some say it’s already here.) Some LESS and Sass concepts, such as centralized variables and logic, also offer a smooth transition to a course on JavaScript and jQuery, in which similar concepts would be important.
  • Covering responsive design frameworks is not a bad idea.
    If there’s time left in class, this is a great topic to explore. I’d recommend covering Bootstrap if you’ve taught LESS, or Foundation if you’ve taught Sass. Students will learn how to read someone else’s code (an important skill!) and how to read documentation; they will also learn new technology, as well as explore the positives and negatives of using a documented, open-source framework. Finally, they will learn to customize this code for their own purpose.

Indirect Skills

I’ve covered skills directly shaped by modern front-end Web development. I’d also suggest covering some indirect skills, as part of either these courses or other courses that the students take.

  • The Open-Source Philosophy
    Rather than teach students that open source is free (like beer), teach them that open-source projects survive based on contributions. Introduce GitHub, and explain how people can download, fork and post their own code online. Acquaint students with open-source communities, and have them investigate the types of contributions most valued by these communities.
  • Online Portfolios

    These have been integrated in curricula for several years now, but they tend to be used more by designers than by developers. With portfolios, audiences can focus on the visual design itself, rather than on the code or philosophy behind the work. Make sure students are accustomed to posting code for review (linking to their own GitHub page is a great touch).

    Have students explain the problems they have been trying to solve and why they took the approach they did to solve them. Blogging should be required, so that students can track interesting articles, new approaches to problems, code snippets of interest and so forth. Encourage students to develop a professional social-media presence, focusing on their code and work.

  • Understanding And Modifying Someone Else’s Code
    As open source continues to gain acceptance and respect in the corporate world, the ability to understand someone else’s code and to modify it will increase in importance.
  • Identifying Trends
    What are game-changers for how we approach Web development, and what are passing fads? What skills should we be learning now? (There’s always something new to learn.)
  • Learning How To Learn Technology
    Students can’t always expect a teacher to spoon-feed them what they need to know next. They need to figure out how to learn without courses or books in order to stay on the cutting edge. Help students curate interesting blogs and social-media resources for finding tips and techniques.

Guidelines For Teaching New Students

Many talented Web designers and developers find teaching beginners to be tedious and difficult. Part of the problem is that a high-level developer knows so much information without realizing it. When was the last time a professional seriously had to think about syntax, file management, the order of styles in a style sheet, the correct markup for a page and so forth? Professionals encounter these issues many times per day, but they are all new to the beginning student.

  • Provide an overview.
    Fit the topic of interest in the larger Web universe. For example, what is HTML? What does the acronym stand for? Where was it developed? Can HTML stand on its own as a Web page? Who needs to know HTML? How does CSS fit with HTML? Don’t spend long on this overview. The idea is to orient students, giving the big picture. The details will get filled in as they work with the language. This material can be presented via slides or a whiteboard. As always, involve students in the discussion, and watch out for confusion. Make sure they understand the overview before moving on to code, or else the code will make no sense.
  • Write code with the class.
    In an in-person teaching environment, I like to open a text editor and project my code overhead, with students following along with their computers. This keeps them engaged. Some students find that they don’t type along with me well, whether because they have a different learning style or poor typing skill. In these cases, I encourage them to pay close attention, while some others will write notes and code snippets with pen and paper. If you are teaching online, I’ll do the same type of presentation, using Camtasia to capture my code on screen with a voiceover. In both cases, provide your files to all students, so that they can see your work. Comment frequently in your own code so that they understand your notes and examples.
  • Write code a little at a time, slowly making the examples more complex.
    Don’t introduce too many items at once. For example, as you introduce CSS, start by writing styles for HTML tags. Show how styling the body tag can control the entire Web page, including background color, font, size, etc. Write one attribute at a time, saving the change and displaying it in the browser every time, so that students see exactly which line of CSS controls which element on the page.
  • Ask questions along the way.
    Ask students to come up with solutions to challenges one might encounter when building a page, before confirming how to do it. If they can explain the idea conceptually, then the code becomes easy. For example, if you’ve styled the body of a Web page with blue text, ask how you would make the main heading red. If the students can explain that you’d need to somehow change the text in the h1 tag to be red, then they are doing very well. Then, you’d simply need to show them how to write that as code.
  • It’s hard to keep things simple, and easy to make them complicated.
    Students will ask complex questions along the way. For example, they might notice along the way that red can be written as #ff0000, red or rgb(255,0,0) and will ask what the differences are between them! Try to avoid a scenario such as this early on. Present a single way to write colors (I suggest #ff0000), and don’t revisit the issue until students have mastered this method. Perhaps later in the course, the students will notice rgb(255,0,0) in someone’s sample code; at that point, explaining the differences will be fast and easy. But in the beginning, when little makes sense and there is much to remember, too much information can be overwhelming.
  • Syntax is challenging.
    Beginning students forget to close tags, forget semicolons, make up tags entirely and make many other mistakes. Finding those mistakes is sometimes easy and other times challenging. I like to introduce the topic of validation fairly early in the process, so that students have an easy way to check their work. In the beginning, you might need to point out missing, extra or unclosed syntax, but teaching them robust debugging techniques from the beginning will help them significantly.
  • Managing files is a challenge.

    For most students in introductory HTML and CSS courses, file management is a constant problem. Some will have trouble differentiating between saving information on a hard drive versus saving on a thumb drive, and some might not know the difference between a file and a folder. You might need to explain the fundamentals before teaching how to manage files on a website. I try to keep all of a project’s files in a single folder on the desktop to start, because students can generally find the desktop, and a single folder leaves little room for confusion. All HTML, images and CSS are then saved in that single folder. It’s manageable at first, because students will require only a handful of assets for their first few websites. By the time students feel like one folder is getting cluttered and they’d like some more organization, they will have mastered how to link two files, insert an image and so on. They will know how the code is supposed to look and work; so, if some code isn’t working, they will reasonably assume that the culprit is a malformed path.

  • Remember that you are not designing for a client.

    A common mistake among talented instructors is to make their in-class sample Web pages beautiful, tweaked to perfection and cross-browser compatible from the very beginning. Unfortunately, that’s not the point. Beginners can easily discover beautiful designs by surfing the Web. Also, you are the instructor — you don’t have to prove your competence in this way. Your job is to show them clearly what each line of code does and how it affects the Web page, both in appearance and functionality. When I’m writing code with students, I insert a lot of hideous background colors and borders in the CSS to demonstrate the concepts. I encourage students to use this same method to debug CSS. Don’t give away too much CSS too quickly. The students will push to make things prettier themselves, unsurprisingly — many of them will be graphic designers and will hate how ugly their early Web pages are. However, when students see progress in their designs, from the first HTML page with no styling to a few basic CSS styles and finally to a full layout, they will be patient with you if you explain that a particular question is complicated or premature at this point.

  • You are laying the foundation for their career.
    Graphic design, HTML and CSS are critical skills that professional designers work with every single day. Writing clean, efficient code, understanding how to debug problems, researching better ways to address problems, resolving cross-browser compatibility issues — these are foundational concepts in the life of a front-end developer. I’ve seen students suffer greatly from bad introductory instructors. Your job is incredibly important; so, go slowly with new material, and make sure students have a solid understanding of it before moving on to the next topic.

Moving Forward

If you’re a working professional who also serves as one of the many instructors of website design and development in higher education or if you’re a full-time instructor, how do you address these early Web design courses? How would you suggest that colleges and universities improve their curricula? Post your thoughts in the comments or via Twitter using the hashtag #webeducation.

(al) (ea) (il)

A Journey Through Beautiful Typography In Web Design


  

First impressions are lasting impressions. Whether you realize it or not, your typography helps to create an experience for users before they’ve even read a word or clicked a button. Typography has the potential to go beyond merely telling a story — it shows the user who is behind the website and what you’re about. The treatment of type creates an atmosphere and elicits a response much the same way as tone of voice does.

You need to ask yourself, what do you want to say and how do you want to say it? Consider the user: What do you want them to feel and experience when the page loads? Typography establishes a mode of communication and, in turn, the personality of the website. The choice of typeface will determine how people respond to your website.

The following websites have very distinct personalities, largely established by the typography. Granted, sometimes they aren’t perfect (unfortunately, performance is often an issue), but they use type to engage the user and generate interest. Good Web typography isn’t just about a beautiful visual treatment, but about speed as well; many designers neglect performance entirely. Please keep in mind that these websites haven’t been tested in old browsers or on mobile devices — that wasn’t the point of this article. Instead, we’ll look closely at interesting treatments and innovative uses of type.

Exquisite Uses Of Type

Matt Luckhurst
This page is colorful and fun. You are greeted with lovely serif letters — and after a bit, you realize that the seemingly randomly scattered letters spell Matt’s name. It’s quite effective how hovering reveals a sample image of each project; it almost jumps out of the letter. The website shows how type can be used as graphic elements and incorporated into a design. The multicolored serif typeface breaks away from the classic, maybe even sober, idea we may have of serifs.

Matt Luckhurst

Playful
Well, this is definitely playful! The tone of the website is set not just by the look of the typeface, but by the way it’s displayed. It breaks the mold of communication. You would usually see axial typography on printed posters, which can be effective. On this website, the font choice isn’t particularly decorative or playful; it’s a rather simple sans serif. A nice touch is the background pattern, which mimics the reading direction and the movement of the user’s head from side to side as they read the text.

This is Playful

Atelier
This website is altogether remarkable. The page has such a dynamic feel, created by the different elements on it. The nameplate is in a bold yet elegant typeface, setting the tone for the design. A sense of movement is established by the diagonal lines, which follow the slant of the “A” in the nameplate, setting the rhythm for the website. The movement of the slideshow of teasers grabs your attention, and the images are large without feeling cramped. However, the main background image of the website is 2560 × 5350 pixels and 2.4 MB — ouch!

Atelier

Cirq
Designed to look like an old poster, this website for a vineyard is quite unique and innovative. The design successfully achieves a vintage feel and translates beautifully as a website. I love how the shadow behind “Russian River” moves with your mouse and creates movement on the otherwise static page. The main drawback here is that, for some reason, the text is embedded as images on the website, preventing it from being copied and pasted. Also, surely a similar design could be created at less than 3.4 MB and 43 HTTP requests.

Cirq

Max Di Capua
The layout and typography here work together in a modular system, often overlapping one another. This approach to layout is refreshing because it isn’t rigid and has a fluidity to it. The typography has the same feel because it is widely spaced, despite being heavy and dense. Captions and descriptions, in an easy-to-read serif typeface, appear alongside the work.

Max Di Capua

Rijksmuseum
The large letters in a custom typeface span the screen and continue off page, making the Rijksmuseum seem larger than life. The home page then rotates through beautiful photographs of the museum’s contents. The main navigation is also rather interesting; when clicked, it slides down for users to select a subcategory. The total size of the home page is 955 KB with 31 HTTP requests — well optimized.

Rijks Museum

I Shot Him
This Web design studio greets you with a photographed welcome message, which is refreshing. The user immediately gets a sense of the physical space that these designers work in. There is a rawness to it, an authenticity. The type is the focal point without being loud or overwhelming. I really like how they have moved away from the perfection of the computer and show themselves as being unique. Although the home page isn’t as interactive as you’d expect, the personality of the design studio is established by the photograph, which has depth and texture.

I Shot Him

The hand-rendered type personalizes the website and sets up an expectation of the kind of work the studio produces. The type treatment throughout the rest of the website reinforces a relaxed yet creative energy, as the wording is short and to the point. Another interesting aspect is the navigation; it’s hidden on the landing page, but hovering over an icon provides access to it. As you scroll down, the navigation is revealed and remains fixed at the top.

Banger’s
This website has a lot of character. Banger’s is a down-to-earth eatery specializing in beer and sausage. Its story looks like it’s drawn on the brown cardboard box that its food is delivered in. The logo looks like a hand-painted sign, unique and imperfect but all the more beautiful for it. The fixed navigation works well as you scroll down, and the hover effect (turning the words red) is simple yet effective. The type contributes a lot to the visual identity, and the graphics are great — but the performance, not so much. A huge downside is that the home page is 7.2 MB, with 254 HTTP requests. Frankly, that’s unacceptable.

Bangers

Caava Design
Caava Design has sans-serif typefaces, which maintains a neat, clean aesthetic. The typeface used for “Good design is good business” is large, easy to read and obvious, and the italicized introduction stands out. The typography throughout is used purposefully and is not necessarily loud, and the written content doesn’t detract from the portfolio.

Caava Design

However, the small text is perhaps too small to be read comfortably, and the spacing in the justified columns is untidy. The contrast in size also discourages the user from reading the entire website. Again, the visuals don’t justify the size: 5.7 MB and 90 HTTP requests.

The Black Sparrow
The Black Sparrow has a vintage look. The wide variety of typefaces all help to establish an eclectic, rustic feel. The theme for this drinkery and lounge is based on the writings of Charles Bukowski, reflected in the literary elements and old typewriter-style logo. I love the navigation bar and how the icons roll over when you hover them. The website has a definite 1930s feel, and the sparrow illustrations support it. However, with the space available, the font size does seem a bit small to be read easily.

The Black Sparrow

Nocturnal
The beautiful slab serif used here is simple, clean, large and easy to read. It is round and widely set, giving the website plenty of breathing room. The simple, neat layout together with the type treatment give a good overall snapshot of the designer’s work. This website works effectively as a design portfolio; while it doesn’t do anything unusual, it focuses heavily on the artist’s work, and sometimes that’s all that is necessary.

Nocturnal

Marie Guillaumet
The handwritten typeface works beautifully by personalizing this portfolio and giving a sense that the designer is physically involved in the production process. A sense of individuality and uniqueness is connected to the designer and, in turn, her work. The handwritten type also works well with the hand-drawn icons, adding character to the website. It’s almost as though we are peering into her visual diary, getting a piece of the designer herself, which will appeal to prospective clients.

Marie Guillaumet

Vintage Hope
The website’s heading looks like it was painted with a thick paintbrush in big heavy strokes. The typeface is so wonderfully bold and expressive. Together with the beautiful photography that fills the background, it gives the user a sense of the openness and freedom that characterize the organization. Vintage Hope raises money for the less fortunate in Malawi by loaning out vintage china, and the visual identity has an excited, happy and positive look to it. And that’s at 1 MB in size and 40 HTTP requests — impressive.

Vintage Hope

Browser Awareness Day
As this page loads, the user is called upon to help make the Web “fun,” “fast” and “safe.” The keyword in each slide is set in decorative type. Creativity is evident in the lettering, which grabs attention, enticing the user to scroll down and learn more. The note on the right has a comic book-style typeface, adding to the playfulness of the website. When you scroll down, the same comic-book typeface is used, along with other playful typefaces.

Browser Awareness Day

Rob Edwards
The typography here is just beautiful. It’s a design piece in itself and sets up an expectation of the designer’s work. The “Hi there” is large and grabs the user’s attention, and the rest of the decorative circus-style typefaces are engaging and fun. You don’t see this every day, and it works effectively as an introduction. The rest of the website feels a bit out of place, though, especially in its spacing and contrast.

Rob Edwards

82nd & Fifth
This website is all about visuals, and the typeface supports that. The sans serif is beautifully simple and light, and the tinted block backgrounds for the captions are sophisticated. With this website, the typeface isn’t the focal point, but rather supports the strong photographs. The website as a whole is quite dynamic; as you scroll down, more thumbnails are loaded. The website also has a seemingly transparent navigation bar; when it’s hovered over, a black bar folds out to reveal the menu. The whole website is thoughtfully constructed to showcase the art pieces. The downside is its 6.4 MB and 120 HTTP requests.

82nd & Fifth

ECC Lighting & Furniture
Love it or hate it, Helvetica takes center stage on this website. The category buttons are big and bold and grab the user’s attention. The graphic design here is classic, clean and minimalist. The type in the navigation is vertically oriented in the top-right, creating an interesting effect, while still allowing the user’s focus to remain on the main category navigation. The way the images are not shown until the area is hovered over is intriguing.

ECC Lighting & Furniture

Marianne Brandt
What do you expect when you hear the name Marianne Brandt, and how would you translate that into a website? Naturally, a Bauhaus-level focus on functionality is key. This website has a definite Bauhaus feel to it, with its flat colors and Futura font. The overall aesthetic is minimalist and clean but definitely not boring or dull.

Marianne Brandt

What grabbed my attention was the “Thanks / Danke” piece, in which the language you’ve set (English or German) determines which word stands out in bold red. It’s such a great idea for websites that support more than one language. The different sections remind me of colored plastic file dividers, a great way to sort through information on a website. The colors, geometry and overall character are consistent with Bauhaus principles.

Nate Navasca
The style and type treatment on this website are perhaps a little more traditional, with a bold sans-serif headline and a serif typeface for the body text. If it ain’t broke, why fix it, right? The designer focuses on functionality and simplicity, and it works well.

Nate Navasca

Ewket
The design here is flat and simple. Created with basic shapes, it looks like the first layer of a painting. Ewket deals with basic education matters in Ethiopia, and the use of Andale Mono for the body text is not exactly what you’d expect, but it works for the purpose. The font is a sharp sans serif that has a bare and basic feel. Ewket is a grassroots program, so the very basic and simple design mirrors its function. However, it isn’t really reflected in performance: 4.6 MB and 58 HTTP requests are unnecessarily large.

Ewket

The Dissolve
I love the nameplate and how it creates an old cinema aesthetic. The typeface has that vintage feel and contrasts with the serifs used in the articles. The website has the simple, clean and sophisticated appeal of an old movie. The navigation makes great use of the space; once the identity of the website is established with the nameplate, the teasers for each category appear in its place as you hover over it.

The Dissolve

The Whig
This dive bar is a place to sit back, relax and have a drink with your buddies. The typeface chosen to illustrate this is Medula One. This sans serif isn’t overly decorative but has a medieval look to it, with its brushed strokes. It’s friendly and not pretentious, hinting at the ambience of the bar.

The Whig

Find & Form
With a clean, monochromatic aesthetic, this website keeps body text to a minimum. The typography is simple and low-key, allowing the images to speak for themselves. The monospaced font is a bit unusual here; still, it communicates the team’s slogan that “The digital world craves old-school craft.” The aesthetic is contemporary. Also interesting is how navigation moves horizontally as you scroll down the page, making room for the rest of the website.

Find&Form

Carrera
There is a timelessness to the design of Carrera’s website, just as there is an authenticity and timelessness to its products. Website design should be consistent with product design. This eyeglass company cites one of its objectives as being to strike a “perfect balance between heritage and fashion.” The simple, bold uppercase type achieves this, having a classic feel without being outdated or overused. The typography is bold and prominent, although different enough that it doesn’t compete with the logo. Also worth mentioning are the interesting hover effects throughout the different sections of the website.

Carrera

Myfelt
The typography used here is friendly and warm, congruent with the products, text and illustrations. All of the elements work together to communicate the same message. One of my favorite things about this website is that the dots in the rugs are incorporated into the logo and nameplate.

Myfelt

Vogue
The Playfair Display font, by designer Claus Eggers Sørensen, sets a bold yet not brash tone. The elegance of this serif is consistent with Vogue’s brand. According to the designer, the typeface is viewed best at larger sizes.

Vogue

All Saints Estate
There are a few ways to achieve class and elegance with type, and this website hits the nail on the head with its blend of serif and lightweight sans serif. Garamond Premier Pro Display has a contemporary yet sophisticated look that is delicate and perfect for body text and appropriate to vineyards and wine.

Vogue

Evening Edition
The blackletter typeface for this nameplate is consistent with the traditional nameplates of print newspapers. It carries authority and gravitas and separates this news source from tabloids.

Evening Edition

Served MCR
This fun doodle-inspired website is for a ping-pong competition. The typography is rough and looks hand-drawn; in some areas, the type is animated or set against an animated background. Animated type is unusual in Web design, but here it grabs the user’s attention. The “Register” banner is an instance of this; the text is legible and prominent. This typography is appropriate because there isn’t much text, which keeps the website easy to use. However, the performance of the page is devastating: 7.5 MB with 175 HTTP requests. The main background image is 2032 × 4761 pixels and 2.2 MB — on both desktop and mobile.

Served MC

Enso
Large, bold, full-caps sans-serif type can get in your face, as if it’s shouting. However, Enso uses muted tones to counter the bold typography — although, yellow is a little difficult to read. The layout is original and interesting; the designers want you to notice the type running down the page and to scroll down to read the entire message. This is a clever tactic because the navigation is scattered around the page in bright pink. The logo at the top acts as a home button, rolling out to reveal the whole word when hovered over.

Enso

Crafting Type
This website is all about type, so the typography has to sell itself. The contrast between the light uppercase type for “Crafting” and the heavy lowercase typeface for “type” creates visual balance in the logo. The body text is large and legible. The serif typeface and simple elegant layout also contribute to the legibility.

Crafting Type

Nautilus
This beautiful website is neat, clean and easy to navigate. The typography works well, with the three fonts coming from the same family. This is a nice way to differentiate your type while maintaining consistency and not disturbing the aesthetic. Unfortunately, Web typography has its cost: 12.6 MB and 73 HTTP requests, with two enormous images, at 3.5 and 2.4 MB, respectively.

Nautilus

Kick My Habits
The thick bold typeface of “Kick My Habits” is the first thing you see on the page. The skinny typeface (named KG How Many Times), with its charming handwritten feel, contrasts with the heaviness of the other type. The website, a beautifully designed and illustrated quiz that figures out how much money you waste on bad habits, has a relaxed, informal tone. And it doesn’t spend much of your bandwidth either. With all of the imagery on the page, it’s just 1.2 MB, although 161 HTTP requests are initialized upon the initial load; more content is loaded on demand.

Kick My Habits

Monocle
Monocle is a beautiful website with a classic quality. It uses serif and sans-serif typefaces in different weights, staying simple and elegant. Monocle is a global news website, with a focus on international affairs, business, culture and design. The layout is innovative, providing everything that the user could need right there. The categories are organized as tabs, with subcategories to further whittle down the information.

Monocle

Rezo Zero
The custom typeface here by Julien Blanchet is unique and grabs attention. It establishes the identity of the brand, setting a mint green against a monochromatic website. The typeface is neither overused nor underused, translating beautifully as a logo.

Rezo-Zero

More Sleep
Neat but friendly and inviting! Those were my first thoughts upon visiting this website. The large type with slightly rounded corners has a friendliness to it. The typewriter-style font used for the descriptions and explanations has a round, soft, welcoming appeal.

More Sleep

Lenta
Lenta is a Russian news website. It’s amazing how the graphic qualities of the type guide you and influence your perception of the website and its contents. The identity of any news website is established by its nameplate. A clean sans serif is used here, with a weight that conveys authority for the news source. The typeface remains effective when the text is translated into other languages. In keeping with a traditional news layout, articles and teasers throughout the website are in a serif typeface.

Lenta

Pixel Recess
Pixel Recess makes use of the sans-serif Adelle Sans, which is neat and legible and looks great on a screen. The more intriguing type, however, is the headline typeface, Zeitgeist, which has a distorted, pixelated, even blurry appearance, reflected in the playground slide in the top-left corner. Pixelation is traditionally regarded as a mistake, but because the rest of the website is sharp, here it draws attention to itself — a clever tactic indeed.

Pixel Recess

Conclusion

It’s not just about what you say, but how you say it, right? Depending on your purpose, we could try to experiment more and get creative with our typography. We can be bold and daring with strong, large letters, or get quirky and unique with handwritten type. We should keep in mind that type should always be legible, because there’s no point in showing off type that no one can read. Type can do so much for a design if it sets rhythm and creates an atmosphere.

It’s easy to get distracted by beautiful type treatments and large Retina-ready background images. But we shouldn’t neglect performance. Custom Web fonts can slow down loading times, so let’s find ways to counteract that.

Finally, if you’d like to explore more interesting websites with a heavy focus on typography, make sure to visit Typewolf and Font in Use.

(al) (ea)


© Shavaughn Haack for Smashing Magazine, 2013.

Smashing Magazine Feed