Typography enhances the readability of information on a web page, yet — quite ironically — it also helps users avoid reading. This is the true and "most humane purpose" of design. Mind blown?

Applying the principles of typography, designers break up text into blocks and offer visual shortcuts that let users sift through masses of information — making it easier to scan for information.

It’s more convenient for users to decide where to begin reading if content is organized efficiently. The more information a user gets from one glance, the quicker he achieves his goals on a web page and the less time he spends staring at the screen.

A Brief Introduction to Typography

Typography is a tool with which we, designers, can create things. We use it to shape content, give language a physical body and enable the flow of understanding.

From analyzing the basic pixels that make up a well-designed comma to organizing blocks of text along a baseline grid, the study of typography can help us create solid structures of information.

Typography isn’t just about fiddling with fonts and tinkering with typefaces. Typefaces are to designers as glass, steel and stone are to architects.

Typography is about assembling those resources into something sensible and robust—like an architect utilizing industrial materials to build a skyscraper that can withstand the test of weather and time.

Typeface versus Font

Let’s clear this up, shall we?

In both print and digital design, a typeface refers to the visual design of letterforms; a font is simply how those designs are delivered. During Johann Gutenberg’s time, these designs were used to create molds from which metal type casts are made.

A set of metal casts is called a font. These days, however, a font refers to the software that allows us to install and display the design on-screen. Each typeface can consist of different fonts—often representing a single weight or style.

In other words, a typeface refers to a family of fonts (such as Arial) while a font refers to a single member of that family (such as Arial Narrow or Arial Black).

Many designers choose to use these terms interchangeably. Now you know better.

Classifications of Typefaces

Among the various principles of typography, font choice is something we designers must master. Typefaces speak in behalf of a brand or a webpage and should reflect its personality.

By understanding the different classifications of typefaces, you will be able to combine them effectively. Nowadays, there are many different kinds of typefaces to choose from. The three most popular ones are: serif, sans serif and monospace.

Serif typefaces are characterized by tiny lines (serifs) trailing from the edges of the strokes and stems. Also called "roman" typefaces, they are often used for headlines and narratives. Examples of serif typefaces include Georgia, Times New Roman, Palatino Linotype, Adobe Garamond Pro and Cambria.

Sans serif typefaces, on the other hand, lack these tiny lines. The French word sans means "without"—hence the name. While serif typefaces are considered serious and elegant, sans serif typefaces are regarded as modern and dynamic.

Due to their simplicity, they are easier to read on a computer screen, even at very small sizes—perfect for body text in web pages. Examples of sans serif typefaces include Arial, Helvetica, Verdana and Tahoma.

Often used to display code and plain text on webpages to enhance their readability, monospace typefaces are so called because each character shares the same width. Among the most popular monospace fonts are Courier, Consolas and Andale Mono.

Alignment and Proximity

Alignment can both refer to how text is displayed (left to right, in most cases) and how each text block lines up with others. To align typographical elements more effectively, many designers rely on grid systems. Simply put, a grid system is a set of vertical and horizontal lines that a designer can use as a guide to strengthen the structure of a web page.

Proximity is also important. Keep related elements closer together with enough white space to make each of them distinct. For example, adding distinct vertical white space between paragraphs enhances readability and is often employed by news websites.

Measure

Measure refers to the width of a line in a paragraph or column. It should never be too wide or too narrow. Too wide, the blocks of text will be harder to read—eye movements tend to be jittery when forced to continuously follow a horizontal path. Very narrow lines of text, on the other hand, allow for more pauses in thought, making it easier to lose track of context and meaning.

Leading

Leading, also called line height, refers to the amount of space between lines in a block of text. Striking a balance between font size and line height can drastically improve readability and "scannability." White space, if set right, should guide the reader’s eyes along the flow of content, not distract them from it.

A very small line height value makes text seem congested; a very large value makes it difficult to distinguish each paragraph.

Weight

Weight refers to the "thickness" of a font compared to its base typeface. We think of weight in terms of "bold," "light," "normal," etc. Many typefaces, however, are already either heavy or light to begin with. When combining typefaces for a design and creating balanced typographical contrast, consider weight first. It’s also a good idea to choose a typeface with distinct weights.

Don’t Stop Learning

This is just the beginning. Typography is about bringing these basic elements together to form a coherent, robust design. It may take a while for you to develop your skills in typography, but with patient practice and constant vigilance, you’ll master it in no time.

The post The Principles of Typography: Back to Basics appeared first on Speckyboy Design Magazine.

Almost every programming book pays lip service to reading code, but few actually teach you how to read code. The peculiarities of a language and a coder’s personal idiosyncrasies can make a piece of code frustratingly difficult to read. You can’t really print out some open-source code, grab a cup of coffee and thumb through it leisurely as you would with a novel; there needs to be active engagement with the code and a continuous attempt to analyze its conceptual basis.

According to a research paper by the University of North Carolina’s CS department, we do not actually “read” code but, trained by habit, scan it for any recognizable mistakes, going through the function headers, then the function body, and finally resting our eyes where errors mostly reside, the loops. Effectively, what we call ‘reading’ actually amounts to actively scanning and comprehending code.

Learning how to read code efficiently is a skill that often sets apart excellent coders from the merely good. But it’s a skill that can be easily learned, especially by picking through examples of high-quality code. GitHub and CodePen are excellent resources for finding well written open-source code in a variety of languages.

Reading these five books with their heavy emphasis on writing and reading code will also take you a long way in acquiring this skill:

1. Code Reading: The Open Source Perspective

One of the few books to tackle the subject of reading code head on, this should be the starting point for anyone trying to learn how to read, and eventually, write good code.

This book works on the example method: the author, Diomidis Spinellis, a PhD in Computer Science from Imperial College, London, digs through over 600 real world examples to analyze how they work, how to read, and how to understand them.

2. Code Quality: The Open Source Perspective

A sister book to the above entry, ‘Code Quality’ uses real-life examples from open source projects to teach you how to write quality code. While not a particularly easy read, it is nevertheless a good book to buy for the budding programmer. Most of the best programmers in the world learn the foundational basis of writing quality code through years of experience; this book simplifies the process by providing helpful examples of well written code culled from hundreds of open source projects.

The purpose of the book might be oriented towards non-functional aspects of programming such as structure and problem solving, but the advice is equally useful for coders who want to learn how to read code.

3. Clean Code: A Handbook of Agile Software Craftsmanship

This book extols the virtues of clean code (even though the author, Robert C. Martin, maintains throughout the book that writing clean code is a ‘lot of hard work’) and approaches the process of writing code almost as an artist would approach an easel. Software engineering is compared to craftsmanship; the end result, therefore, must be suitably clean and sufficiently alterable by others.

4. Refactoring: Improving the Design of Existing Code

Refactoring is the process of altering the internal structure of a software program without affecting its actual functions. The end process leads to better designed, more readable, and more ‘coherent’ code that’s much easier to manage and modify.

Much can be learned about reading (and writing) code from the process of refactoring, namely, how to spot errors in code design. Learning about refactoring (a useful skill by itself) helps you read code better, as you will already be thinking about what changes should be made and how they should be made.

5. Code Complete: The Practical Handbook of Software Programming

Steve McConnell’s masterpiece, Code Complete, can be usually found proudly displayed on the shelves of programmers all around the world. Indeed, this seminal volume in programming literature has enjoyed tremendous success over the years, and is often dubbed the “coders’ Bible.”

Code Complete focuses on the principles of good programming, teaching with examples from academia as well as real life.

Going through the well-written code samples (and McConnell’s insightful commentary) is an education in itself, and will teach you not just how to read code, but also how to think like a top notch programmer.

The post 5 Essential Books for Learning to Read Code appeared first on Speckyboy Design Magazine.

Distributing any work – a piece of code, a software program, or even markup – under an open source license implies that the original creator has granted specific permissions to re-use and re-distribute the work without prior approval. It does not equate to a relinquishing of all copyrights; instead, it facilitates the use of existing work by other programmers and developers, provided they credit the original author.

Not all open-source licenses offer the same provisions and copyright protection, however. Each open-source license must be approved by the Open Source Initiative (OSI). While the OSI approved-license count stands at 67, only a few of these are widely used by programmers.

Below, we’ll cover ten most-used open source licenses:

1. General Public License (GPL)

Approved in February 1989, the GPL is the most commonly used license for open source work with over 50,000 SoureForge.net projects in existence. Version 3.0 of the GPL includes provisions for others to copy and modify your code, but only if they include attribution to the original in the source code. The GPL also includes strong ‘copyleft’ measures.

‘Strong’ copyleft measures imply that any program that uses your code must be distributed under the same license. ‘Weak’ copyleft measures do not necessitate this restriction. Essentially, this dictates that if you borrow GPL licensed code, you have to release the finished software under GPL license too, and not any paid or proprietary license.
GPL v. 3.0 also provides direct patent protection – a provision lacking in most open-source licenses.

GPL includes provisions to allow you to sell the open-source software, but only if you explicitly mention that the software is open-source and can be downloaded for free.

2. GNU Library or Lesser General Public License (LGPL)

The LGPL includes fewer measures of protection than the GPL with only indirect patent protection and weak copyleft measures. This has made the LGPL the license of choice for libraries, as code licensed under the LGPL can be used in paid and proprietary software.

Only changes to the library code itself must be open-sourced; the remainder of a project using LGPL code may remain closed-source. The LGPL license was approved in June 1991 and covers over 8,000 SourceForge projects.

3. BSD License

The BSD license comes in multiple flavors, of which, the two most popular ones are BSD-3-Clause (or “New BSD license”), and BSD-2-Clause (“FreeBSD license). These two licenses offer less protection than the GPL, and simultaneously, fewer restrictions on distribution.

Both BSD licenses provide unlimited redistribution without any patent protection or copyleft measures. The BSD-3-Clause license differs from BSD-2-Clause in that it includes an anti-endorsement provision. Basically, this means that if you’ve contributed to any work, your name cannot be used to endorse or advertise the work without express permission.

4. MIT License

The MIT License is the oldest open-source license still in use and dates all the way back to September of 1987. It is also the broadest of all licenses with very sparsely defined provisions regulating distribution, endorsement and copyleft measures. Essentially, it provides for anyone to modify, copy and use any piece of the code or software howsoever he wants, as long as the finished product includes a copy of the license.

An update to the license – the MIT/X11 license – adds an anti-endorsement provision. This is the least restrictive open-source license and has over 1300 SourceForge.net projects in existence.

5. Mozilla Public License 2 (MPL 2.0)

Initially approved in 1998, the first version of the MPL (MPL 1.0) was more “business friendly” and included fewer copyright measures than the GPL. A January 2012 revision to the license – MPL 2.0 – corrected compatibility issues with the GPL and Apache licenses.

Broadly, the MPL 2.0 is compatible with both the GPL and Apache licenses (a provision lacking in MPL 1.0) and may be combined with proprietary code in a “larger body of work”. It also includes direct patent protection, and must include attribution in the source code.

6. Apache License v 2.0

The first version of the Apache license was drafted and approved in 1995. The Apache license is broad in its scope and grants significant rights to copyright holders. Specifically, it dictates that all rights are perpetual, global, non-exclusive, and irrevocable. Once granted rights, you are free to use them forever, anywhere in the world, and no one can take them away from you.

The non-exclusivity clause means that anyone can use the licensed work.
Besides, the v 2.0 of the Apache license also includes patent protection. It doesn’t include any copyleft measures, which means it is compatible with paid and proprietary software.

Image Source

7. Eclipse Public License (EPL)

The EPL was published by the Eclipse Foundation in 2004 and borrows most of its clauses from the GPL. The EPL superseded the Common Public License (CPL), originally published by IBM in 2001.

The EPL’s primary aim is to facilitate collaborative open-source development by allowing it to work with proprietary licenses. Consequently, it includes weak copyleft measures and is thus incompatible with the GPL. Under the EPL, anyone can edit, modify, copy and distribute any work, provided it does not borrow any work licensed under GPL.

8. Common Development and Distribution License (CDDL)

The CDDL is based on the MPL v 1.1. The CDDL is compatible with most open-source and proprietary licenses, save the GPL. It includes limited copyleft measures, and measures that allow anyone to edit, modify and use code with appropriate attribution in any work, commercial, or otherwise.

9. Open Software License (OSL)

The OSL is similar to LGPL in its clauses and weak copyleft measures, but differs from it in one crucial aspect: the OSL includes a ‘patent action termination clause’. Essentially, this means that the license is terminated automatically as soon as anyone files a patent infringement lawsuit. It also includes a clause that dictates that all derivative works must be distributed under the OSL license.

10. Academic Free License (AFL)

The AFL was published in 2002 in an attempt to remedy the deficiencies of the BSD, MIT and Apache licenses. It provides similar measures for redistribution, modification, and attribution, but adds a few more clauses that include patent and copyright grants for the software. The AFL is incompatible with the GPL on account of its lack of copyleft measures.

The post Understanding Which License to Choose for Your Code appeared first on Speckyboy Design Magazine.

A number of well-known companies have redesigned their logos recently, and some have even gone so far as to redesign their entire brand identity system.

Below I have outlined a number of corporate logo redesigns with successful results.