10 useful typography tips to improve your website readability

Published on July 16th, 2012 by Jean-Baptiste Jung.

Typography is often neglected on websites. This is a shame, because by improving your typography, you'll improve both your website design and readability. In this article, I have compiled 10 extremely useful typography tips that will help you to make your website looks better.

Correct line height

One of the most common web typography mistake is definitely an incorrect line height. Line height define the height of a line of text, so it have to be set according on the font size.

As a rule of thumb, I always add 7px to the font size when setting line height on texts (with 12 to 15 pixels font size)

body{      font-size:14px;      line-height:21px; /* 14px + 7px */  }  

Correct title margins

Another common mistake is an incorrect margin around titles. A title is related to a paragraph, it is not a separator between two paragraphs. This is why a title should have a wider margin on top than on its bottom.

Don't use too many different fonts

In order to keep your website readable and professional, you shouldn't use more than 3 different fonts. Using too many fonts can be confusing for the reader and will make your website look cluttered.
On the other hand, using fewer fonts keeps your website clean and readable. You can use one font for headings, one for the text, and eventually another one for the logo or the subtitles.

Use monospaced fonts to display code snippets

If you're a developer (like most persons reading this blog) you probably want to display some code snippets on your blog. If yes, please use a monospaced font to do so. So, what's a monospaced font? It's a font whose letters and characters each occupy the same amount of horizontal space.

So, which fonts should you use to display code snippets on a website? Courier is by far the most popular, but what about giving a try to most recent fonts such as Consolas or Monaco? And if you want even more choice, you should definitely have a look there.

Care about contrast

Even if your website have a great typography, another point to consider is contrast. If your page background is grey (#999999), then do not use a dark grey text (#333333) otherwise your content may be hard to read, especially for older people or people with visual disabilities.

Generally, excepted if your site is about hacking, black hat seo or gothic rock, you should use a light background and a dark font to keep a bright contrast and increase your site readability.

Keep underlined text for links

Since I've started using the internet twelve years ago, the default style applied to links by browsers is a blue text with an underline. Althought the blue is often changed to another color, the underline has been since recognized as the generic style for links. This is why you should never use underlined text for other things than links. Otherwise, this can be very confusing for your readers.

Create a library of styles

A simple and effective way to make your website visually stunning is create specific styles for specific usages. For example, what about creating a .warning CSS class to display warnings to your readers?

Hierarchize titles and text

In order to improve readability, creating a hierarchy consisting of titles, intro paragraphs and regular text is important because they allow your readers to visualize your articles and quickly access to the part that they're interested in.

Don't be afraid of white space

One of the best typography tip I've received is "Don't be afraid of white space". White space is not blank space nor unused space, it make your design clutter-free and professional. Many people love Apple's website for that reason: It's sophisticated but simple, and have lots of white space.

Use the right symbols

An important point to consider if you're looking to improve your typography is the use of the rights symbols. For example, double prime symbols are often used instead of quote symbols.
Note the difference betwen the double prime verison:

He said "Hello".

And the same text, using quote symbols:

He said "Hello".

Better, isn't it? If you're a WordPress user, you'll probably be happy to know that your favorite blogging platform automatically transform double primes into smart quotes. Otherwise, you should use HTML entities as shown below:

He said &s;ldquo;Hello”.

10 Reasons Why Visual Basic is Better Than C#

07 March 2012

by Andy Brown

After having converted a whole lot of training materials based on VB.NET into C#, Andy 'Wise Owl' Brown decided to write a tongue-in-cheek rant whilst he could still remember the pain-points. 'Convert to VB.NET! You have nothing to lose but your semi-colons! '

Visual Basic is a better programming language than Visual C#. Who says so? This article! Here are 10 reasons why you should always choose VB over C#.

1 – "Rose is a rose is a rose is a rose"

This is a quotation from Gertrude Stein's 1922 play Geography and Plays. However, the poetry wouldn't work in C#, because – unforgivably – it's a cASe-SeNSitIvE language. This is madness!

Before I start ranting, let me just acknowledge that case-sensitivity confers one (and only one) advantage – it makes it easier to name private and public properties:

Writing properties like this means that you can refer to the public Name property, and it's obvious what the private equivalent will be called (name).

// private version of variable private string name = null; public string Name {     get     {         return txtName.Text;     }     set     {         name = txtName.Text;     } }

So now we've got that out of the way: case-sensitive programming languages make everything else harder. Why, you ask?

• You keep having to switch between upper and lower case when typing, causing RSI in your poor little fingers as you reach for the inconsiderately located Shift key.
• You are much more likely to make mistakes - are you sure you meant to type DateOfBirth, or should it have been dateofbirth?
• When you accidentally leave Caps lock on, it really matters.

The only possible benefit is that you can use more combinations of variable names, that is, you can use more of one of the few infinite resources in this universe…

It doesn't matter if you disagree with everything else in this article: case-sensitivity alone is sufficient reason to ditch C#!

2 – The Switch clause

Both VB and C# contain a way of testing mutually exclusive possibilities, the Select Case and Switch clauses respectively. Only one of them works properly.

A Visual Basic Select Case clause, returning a description of how old someone is. The age range for a young person is a tad generous, reflecting the age of the author of this article.

A Visual Basic Select Case clause, returning a description of how old someone is. The age range for a young person is a tad generous, reflecting the age of the author of this article.

Select Case AgeEntered     Case Is < 18         txtVerdict.Text = "child"     Case Is < 50         txtVerdict.Text = "young person"     Case Is < 65         txtVerdict.Text = "middle-aged"     Case Else         txtVerdict.Text = "elderly" End Select

You can't do this using Switch in C#, as - astonishingly - it can't handle relational operators. You have to use an If/ Else If clause instead. But even if you could, you'd still have to type in lots of unnecessary Break statements:

switch (AgeThreshold) {     case 18 :          txtVerdict.Text = "child";         break;     case 50 :         txtVerdict.Text = "young person";         break;     case 65 :         txtVerdict.Text = "middle-aged";         break;     default:         txtVerdict.Text = "elderly";         break; }

It's easy to forget to type in each of these Break statements!

3 – Event-Handling code

This is specific to Visual Studio (I'm using 2010, the latest version). Suppose I want to attach code to anything but the default Click event of a typical button:

Let's suppose that I want to attach code to the MouseHover event of this button.

I can do this in Visual Basic without leaving the code window:

a) First choose the object from the drop list.

b)Then choose the event you want to code.

In C# you can't do this – you have to return to the button's properties window and choose to show its events:

You can double-click to attach code to this event for the selected button – but that's the only simple way to create it for C#.

But it's even worse than that. If you then rename a control (in this case btnApply) you have to re-associate the event-handler with the renamed control in the properties window (or in the initialisation code, if you can find it). In Visual Basic, of course, you can do all of this in code:

Private Sub btnApply_Click(ByVal sender AsSystem.Object,         ByVal e As System.EventArgs) Handles btnApply.Click           MessageBox.Show("Hello")       End Sub

Globally change btnApply to the new button's name in code, and everything will work as before.

4 –Stupid symbols

C# was written by academics. It shows. Consider this table of C# symbols and their VB equivalents:

What you're trying to do	C# Symbol	VB Equivalent
Test if two conditions are both true	&&	and
Test if one or other condition is true	||	or
Test if a condition is not true	!	not
Concatenate two strings of text	+	&
Test if a condition is true within an if statement	==	=

Which column looks like it was designed by a real person?

5 – Autocorrection in Visual Basic actually works

IntelliSense works much better for Visual Basic than for Visual C#. Take just one example – creating a write-only property. Let's start with Visual Basic:

	When you press return at the line end…
WriteOnly Property PersonName As String         Set(value As String)           End Set     End Property	… You get this fully-completed clause.

For C#, the same thing doesn't happen:

When you press return here, nothing happens (other than a blank line appearing).

This is just one example. I've just spent ages transcribing our VB courses into C#, and believe me, there are many, many more!

6 – Lack of supported functions

Here are a couple of functions I use from time to time in VB:

Function	What it does
IsNumeric	Tests if a value can be converted to a number
PMT	Calculates the annual mortgage payment for a loan

Great functions, but they don't exist in C#.

7 – That wretched semi-colon

Why do I have to end every line in C# with a semi-colon? The argument used to be that it avoided the need to use continuation characters in Visual Basic:

MessageBox.Show( _     text:="This article is a bit opinionated", _     caption:="Message")

You used to have to use an underscore as a continuation character to show incomplete lines of code in VB.

However, as of Visual Basic 2010 you rarely need to do this anymore. Come on, C#: Visual Basic has ditched its line-ending character; why can't you?(;)

Someone commented on my original (much shorter) blog about this:

    "In a short amount of time you'll type those semi-colons without thinking about it (I even type them when programming in visual basic)." 

That's like saying that you'll soon get used to not having any matches to light your fire, and you'll even start rubbing sticks together to start a fire when you finally manage to buy a box!

8 – Arguments and variables

The order of words in a C# variable declaration is wrong. When you introduce someone, you wouldn't say, "This is my friend who's a solicitor; he's called Bob". So why do you say:

string PersonName = "Bob";

To me:

Dim PersonName As String = "Bob"

…is much more logical. I also find the C# method of having to prefix arguments with the word out confusing, particularly as you have to do it both in the called and calling routine.

9 – Strictness

C# is a much fussier language than Visual Basic (even if you turn Option Strict on in Visual Basic, this is still true). "And a good thing, too!", I hear you cry. Well, maybe. Consider this Visual Basic code:

Enum AgeBand    Child = 18    Young = 30    MiddleAged = 60    SeniorCitizen = 90 End Enum Select Case Age     Case Is < AgeBand.Child         MessageBox.Show("Child")     Case Else         MessageBox.Show("Adult") End Select

With Option Strict turned on this shouldn't really work, as it's comparing an integer with an enumeration – but VB has the common sense to realise what you want to do.

The equivalent in Visual C# doesn't work:

A less forgiving language…

What this means is that you end up having to fill your code with messy type conversions:

The simplest way of converting an enumeration to an integer; but why should you have to?

// find out the age entered int Age = Convert.ToInt32(txtAge.Text); if (Age < (int) AgeBand.Child) {     MessageBox.Show("Child"); } else {     MessageBox.Show("Adult"); }

10 – Redimensioning arrays

If you want to dynamically change the length of an array in Visual Basic, you can use Redim Preserve. To do the same thing in Visual C#, you have to copy the array, add a value and then copy it back:

The vile, clunky C# method of extending an array.

string[] PartyGuests = new string[2]; PartyGuests[0] = "Sarah Palin"; PartyGuests[1] = "Richard Dawkins"; // whoops! forgot to invite Mitt // create a new extended array string[] tempGuests = new string[PartyGuests.Length + 1]; // copy all of the elements from the old array into new one Array.Copy(PartyGuests,tempGuests,PartyGuests.Length); // add Mitt as last element tempGuests[PartyGuests.Length] = "Mitt Romney"; // restore full list into original array PartyGuests = tempGuests; // check works foreach (string Guest in PartyGuests) {     System.Diagnostics.Debug.Write(Guest); }

This epitomises Visual C# for me. Critics will tell me that:

• Behind the scenes, the Redim Preserve command does exactly the same thing as the C# code above; and
• I should be using lists and not arrays anyway.

That's hardly the point! The point is that - as so often - Visual Basic makes something easier to code than C# does.

Conclusion

So those are my 10 reasons to code in Visual Basic. What are you waiting for, all you C# code-monkeys? Convert all of your code to VB – you have nothing to lose but your semi-colons!

C# Coding Standards

Here are our C# coding standards, naming conventions, and best practices. Use these in your own projects and/or adjust these to your own needs.

1. Naming Conventions and Style
do use PascalCasing for class names and method names.

public class ClientActivity

{

    public void ClearStatistics()

    {

        //...

    }

    public void CalculateStatistics()

    {

        //...

    }

}

Why: consistent with the Microsoft's .NET Framework and easy to read.
do use camelCasing for method arguments and local variables.

public class UserLog

{

    public void Add(LogEvent logEvent)

    {

        int itemCount = logEvent.Items.Count;

        // ...

    }

}

Why: consistent with the Microsoft's .NET Framework and easy to read.
do not use Hungarian notation or any other type identification in identifiers

// Correct

int counter;

string name;

// Avoid

int iCounter;

string strName;

Why: consistent with the Microsoft's .NET Framework and Visual Studio IDE makes determining types very easy (via tooltips). In general you want to avoid type indicators in any identifier.
do not use Screaming Caps for constants or readonly variables

// Correct

public static const string ShippingType = "DropShip";

// Avoid

public static const string SHIPPINGTYPE = "DropShip";

Why: consistent with the Microsoft's .NET Framework. Caps grap too much attention.
avoid using Abbreviations. Exceptions: abbreviations commonly used as names,
                 such as Id, Xml, Ftp, Uri

// Correct

UserGroup userGroup;

Assignment employeeAssignment;

// Avoid

UserGroup usrGrp;

Assignment empAssignment;

// Exceptions

CustomerId customerId;

XmlDocument xmlDocument;

FtpHelper ftpHelper;

UriPart uriPart;

Why: consistent with the Microsoft's .NET Framework and prevents inconsistent abbreviations.
do use PascalCasing for abbreviations 3 characters or more (2 chars are both uppercase)

HtmlHelper htmlHelper;

FtpTransfer ftpTranfer;

UIControl uiControl;

Why: consistent with the Microsoft's .NET Framework. Caps would grap visually too much attention.
do not use Underscores in identifiers. Exception: you can prefix private static variables
                    with an underscore.

// Correct

public DateTime clientAppointment;

public TimeSpan timeLeft;

// Avoid

public DateTime client_Appointment;

public TimeSpan time_Left;

// Exception

private DateTime _registrationDate;

Why: consistent with the Microsoft's .NET Framework and makes code more natural to read (without 'slur'). Also avoids underline stress (inability to see underline).
do use predefined type names instead of system type names like Int16, Single, UInt64, etc
         

// Correct

string firstName;

int lastIndex;

bool isSaved;

// Avoid

String firstName;

Int32 lastIndex;

Boolean isSaved;

Why: consistent with the Microsoft's .NET Framework and makes code more natural to read.
do use implicit type var for local variable declarations. Exception: primitive types (int, string,
          double, etc) use predefined names.

var stream = File.Create(path);

var customers = new Dictionary<int?, Customer>();

// Exceptions

int index = 100;

string timeSheet;

bool isCompleted;

Why: removes clutter, particularly with complex generic types. Type is easily detected with Visual Studio tooltips.
do use noun or noun phrases to name a class.  

public class Employee

{

}

public class BusinessLocation

{

}

public class DocumentCollection

{

}

Why: consistent with the Microsoft's .NET Framework and easy to remember.
do prefix interfaces with the letter I.  Interface names are noun (phrases) or adjectives.

public interface IShape

{

}

public interface IShapeCollection

{

}

public interface IGroupable

{

}

Why: consistent with the Microsoft's .NET Framework.
do name source files according to their main classes. Exception: file names with partial classes
          reflect their source or purpose, e.g. designer, generated, etc.

// Located in Task.cs

public partial class Task

{

    //...

}

// Located in Task.generated.cs

public partial class Task

{

    //...

}

Why: consistent with the Microsoft practices. Files are alphabetically sorted and partial classes remain adjacent.
do organize namespaces with a clearly defined structure

// Examples

namespace Company.Product.Module.SubModule

namespace Product.Module.Component

namespace Product.Layer.Module.Group

Why: consistent with the Microsoft's .NET Framework. Maintains good organization of your code base.
do vertically align curly brackets.

// Correct

class Program

{

    static void Main(string[] args)

    {

    }

}

Why: Microsoft has a different standard, but developers have overwhelmingly preferred vertically aligned brackets.
do declare all member variables at the top of a class, with static variables at the very top.

// Correct

public class Account

{

    public static string BankName;

    public static decimal Reserves;

    public string Number {get; set;}

    public DateTime DateOpened {get; set;}

    public DateTime DateClosed {get; set;}

    public decimal Balance {get; set;}

    // Constructor

    public Account()

    {

        // ...

    }

}

Why: generally accepted practice that prevents the need to hunt for variable declarations.
do use singular names for enums. Exception: bit field enums.

// Correct

public enum Color

{

    Red,

    Green,

    Blue,

    Yellow,

    Magenta,

    Cyan

}

// Exception

[Flags]

public enum Dockings

{

    None = 0,

    Top = 1, 

    Right = 2, 

    Bottom = 4,

    Left = 8

}

Why: consistent with the Microsoft's .NET Framework and makes the code more natural to read. Plural flags because enum can hold multiple values (using bitwise 'OR').
do not explicitly specify a type of an enum or values of enums (except bit fields)

// Don't

public enum Direction : long

{

    North = 1,

    East = 2,

    South = 3,

    West = 4

}

// Correct

public enum Direction

{

    North,

    East,

    South,

    West

}

Why: can create confusion when relying on actual types and values.
do not suffix enum names with Enum

// Don't

public enum CoinEnum

{

    Penny,

    Nickel,

    Dime,

    Quarter,

    Dollar

}

// Correct

public enum Coin

{

    Penny,

    Nickel,

    Dime,

    Quarter,

    Dollar

}

Why: consistent with the Microsoft's .NET Framework and consistent with prior rule of no type indicators in identifiers.

Ref.:http://www.dofactory.com/reference/csharp-coding-standards.aspx