Anatomy of a Typographic Grid | Van SEO Design

---

Anatomy of a Typographic Grid Posted: 31 May 2011 05:30 AM PDT Recently I’ve been trying to expand my knowledge and skills working with typographic grids. On the knowledge side I sought out definitions for the different parts of a grid, specifically a modular grid. I couldn’t find much online and turned to some of the books I have instead. I assume other people have had the same trouble searching and thought it might be helpful if this information was more readily available online. Most of the information in this post comes from Timothy Samara’s book Making and Breaking the Grid. Anatomy of a Grid Grids act as guides for the placement of elements in a design. No matter how simple or complex, grids share some common parts, each fulfilling a specific function. Not every one of these parts needs to be present in every grid. A little further down the page I’ve added an image showing these common grid parts, which you hopefully find helpful as you read through their descriptions below. Format The format is the area in which the design sits. In a book or magazine the format is the page. On a website the format is the browser window. The format defines the live area of a design where type, images, and other media are present. Margins Margins are the negative space between the edge of the format and the outer edge of the content. The proportions of margin help to establish the overall tension (or lack of tension) in a composition. The smaller the margin the more tension is created. Larger margins create more whitespace and help focus attention on the positive space of the design. Larger margins also help the eye find a place to rest and can be a good area to place subordinate information. Flowlines Flowlines are horizontal lines that break the space into horizontal bands. They can be used to help guide the eye across the page and can be used to impose starting and stopping points for text and images to be aligned. When elements are aligned to the top of a flowline it’s called a hangline as the elements appear to hang from the line. Type is often aligned to a series of flowlines equally spaced down the page called baselines. The base of the type sits on the line, hence the term. Aligning type to a baseline can help establish a vertical rhythm in a design. Modules Modules are individual units of space that are separated by regular intervals. Modules are the basic building blocks of grids. When repeated they create columns and rows. Ideally the width of a module will be based on the measure of a line of text. The height would be based on some multiple of the type’s leading or line-height. The upper left corner of a module is considered to be the active corner and the lower right corner, the passive corner. Spatial Zones Spatial zones are fields of adjacent modules. Each field can be assigned a specific function within the design. A long horizontal field might be used to place long horizontal images. A long vertical field might be used for long blocks of text. A large rectangular field might be used for video. Design elements will often be placed inside a field or spatial zone as opposed to a single module. Columns Columns are vertical bands of modules. There can be any number of columns in a grid. More columns leads to more flexibility, but can also make the grid difficult to work with. Column widths can be equal or they can vary across a grid. Rows Rows are the horizontal equivalent of columns. Online it’s harder to plan for rows as the height of the format is often inconsistent and dynamic. On some pages your design may call for a fixed height, though on most pages your design is allowed grow vertically with the content. Gutters Gutters are the spaces separating modules either vertically or horizontally. Typically we think of gutters as the space between columns, but they are also the space between rows. The minimum width or height of gutters should be an ‘em’ though this should usually be larger to better separate columns from columns and rows from and rows. The height of horizontal gutters should be based on the leading or line-height of the type. Folio Folios are created when page numbers are placed consistently in the margin, usually above or below the composition. Running Header or Footer A running header is a guide at the top to indicate your position in a manuscript. You’d find information like title, chapter title, section title, author, etc located here. A running footer is then this information is placed at the bottom of the format. Markers Markers are placement indicators for subordinate or consistently appearing information. Markers can be used to denote the location of folios, page numbers, etc. These last 3 are more commonly found as described in print, but there’s no reason they couldn’t also be used on a website. For example blog posts aren’t usually given page numbers, but they often display the publication date. When present the date is usually shown at the top of the post, but there’s no reason it couldn’t be included in a running header or as a substitute for the page numbers of a folio. Summary As more and more web designers are looking to employ girds on the sites they design it makes sense for us to learn the language of grids in order to better understand them and to better talk to each other about them. When many people talk about grids online there’s often a focus on columns and to a lesser extent baselines. There are more parts to grids though than columns and baselines. Hopefully the diagram above along with the definitions in this post will give you a foundation for the common language of grids to help you further understand explore using grids in your own work.

You are subscribed to email updates from Van SEO Design » Blog To stop receiving these emails, you may unsubscribe now.	Email delivery powered by Google
Google Inc., 20 West Kinzie, Chicago IL USA 60610

iCan't Internet

---

Steps to Take to Speed up Your Slow Internet Connection Posted: 30 May 2011 12:55 AM PDT Having a slow Internet connection can be a frustrating thing. Luckily there are a number of different things that can be checked to speed up the connection when online. Most of these things can... [[ This is a content summary only. Visit my website for full links, other content, and more! ]]

You are subscribed to email updates from iCan't Internet To stop receiving these emails, you may unsubscribe now.	Email delivery powered by Google
Google Inc., 20 West Kinzie, Chicago IL USA 60610

2 And 3 Column Fluid CSS Layouts | Van SEO Design

---

2 And 3 Column Fluid CSS Layouts Posted: 26 May 2011 05:30 AM PDT Over the last couple of weeks I’ve offered some boilerplate code and construction details for 2 column and 3 column fixed width layouts. Let’s continue today with fluid or liquid layouts. The concepts for creating fluid layouts are mostly the same we used in creating the fixed width layouts with a few key differences. Since much of what we’ll do here simply builds on what we’ve done before I won’t go into every detail for developing fully fluid layouts. Instead I’ll direct you to the previous posts and focus here on what’s new and different. 2 column fixed with layout 3 column fixed width layout On the bright side since we’ll skip some of the previously covered details we’ll develop both 2 and 3 column fluid layouts in one post. If you’d prefer to jump directly to the code here’s a link to the demos. Let’s start with the 2 column liquid layout. The HTML If you’ve been following along with this series the html below should look very familiar. It’s the same html we used to create a 2 column fixed width layout with one exception. <div id="header"> <p>Header</p> </div> <div id="content"> <p>Main content</p> </div> <div id="sidebar"> <p>Sidebar</p> </div> <div id="footer"> <p>Footer</p> </div> I’ve removed the container div that wrapped the header, content, sidebar, and footer divs. If you remember the purpose of the container div was to fix the width and then center everything in the browser. Since we don’t need to do either here, we no longer need that container div. Things are already simpler. Nice. The CSS Again this should be very familiar if you’ve been following along. There are only a few differences from what we’ve already seen. body { margin:0 } #content { float:left; width:67%; } #sidebar { float:left; width:33%; } #footer { clear:both; } Naturally since we removed the container div from the html there’s no container in the css. The first new css is to set the margin to 0 on the body. By default the body will have some margin pushing it away from the browser edge. We want our layout to be right up against the edge so we reset the margin to 0. The next difference is we’re specifying widths in % as opposed to px. Since we want our layout to adapt to the size of the browser we have to use a relative measurement instead of a fixed measurement. If you remember the post on the pros and cons of various css layouts I said that fluid/liquid layouts are relative to the browser. That’s why we’re using %. Units like ‘em’ are also relative, but they’re relative to the size of the font, which is internal to the design. There’s really nothing else new here. Just as we did with the fixed width layouts, we’ve floated both columns to the left (we could also float the sidebar to the right) and cleared the footer in both directions. As with the fixed width layouts we can change the location of columns by changing the direction of the floats. #content {float: right} #sidebar {float: left} Gotchas The potential gotcha is in using % as a measurement. Odds are you’ll want to set some padding or margins on different divs within the layout, and you’ll likely reach first for px. You might try to do the same with other measurements in your design as well. However as soon as you start adding absolute units like px you’re moving away from a fluid layout. The idea with fluid/liquid layouts is to have all measurements be relative to the browser window so they can resize in proportion as the window is resized. You also need to watch that % add up to 100%. It’s natural to want 3 columns to have the same width, which would be 33%, but then you’re missing 1%. Better to have two 33% columns and one 34% column. Not a big deal, but something to remember. I should also note that like the fixed width layouts what’s presented here won’t create columns of equal height. The columns in the demo have equal heights, because I’ve explicitly set them to be equal. In practice the column height will change based on what’s inside each. I’ll have a post on creating layouts with columns of equal height in a couple of weeks. 3 Column Liquid Layout If you’ve understood how we set up fixed width layouts and also understood what changed above to make the 2 column fixed layout a 2 column fluid layout, you should already understand how to create a 3 column fluid layout. I’ll spare you further explanation and simply present the code. The HTML <div id="header"> <p>Header</p> </div> <div id="primary"> <p>Primary Sidebar</p> </div> <div id="content"> <p>Main content</p> </div> <div id="secondary"> <p>Seconday Sidebar</p> </div> <div id="footer"> <p>Footer</p> </div> The CSS #primary { float: left:; width:25%; } #content { float:left; width:50%; } #secondary { float:left; width:25%; } #footer { clear:both; } Nothing here should be new. If the above isn’t making sense please refer back to the fixed width layout posts and the little bit of explanation for the 2 column layout above. When it comes to moving columns around you might remember that we needed to use positioning on one of the 3 columns. The same applies here, though we have to remember to set the value of left as a % instead of px. We’ll also set the body to position relative since we’re no longer using a container div. Otherwise the explanation for moving columns is exactly the same as it was for the 3 column fixed width layout. As a reminder for rearranging the columns. When divs are floated in the same direction they’ll display in the same order as they appear in the html. The first div will either be the leftmost or rightmost column depending on whether things are floated left or right. When two divs are floated in one direction and the third is floated in the opposite direction, the lone div will appear either leftmost or rightmost (depending on the float direction) and the other two divs will be displayed (in their floated direction) in the order they appear in the html. When neither of the above works you order the columns by floating the two outside columns left and right and then using positioning on the column in the middle and giving it a left value equal to the width of the left column. Feel free to ask questions in the comments below if you need further explanation or even better look for the detailed explanation in the 3 column fixed width layout post. A Word of Caution About Fluid/Liquid Layouts When I first talked about the pros and cons of different css layouts I mentioned a few about liquid layouts that I’d like to bring up again. With fluid layouts you give up a lot of control over your design. In some respects that’s how the web should work. We should be giving more control to our audience. However there are times when maintaing control over certain aspects of a design is important. A major drawback to fluid layouts is that in allowing everything to resize you allow the measure or length of a line of text to resize without any minimum or maximum. That can and does leads to lines of text either too long or too short, which can be uncomfortable to read. It also means other design elements start reflowing around the text in sometimes unpredictable ways. One way to counter this is by setting some min and max widths. Unfortunately that kind of goes against the point of having the layout be fully liquid and it can also lead to too much or too little whitespace within your design. While I think creating designs that are more fluid and adaptable to the different ways our sites and pages will be be viewed is a goal we should strive for, I don’t care much for fully fluid layouts and can’t remember the last time I used one. I also think that our fluid designs should be relative to something internal to the design and not external to the browser and we’ll get to those designs when we talk about elastic layouts. Summary Once again here’s a link to the demos. As with the fixed width layouts, the html and css here are rather simple. If you understood how to build the former you shouldn’t have any problems with the liquid layouts here. The concepts are pretty much the same. All we’ve done differently with the fluid layouts is remove the container div (which we used to fixed the width and center the layouts) and to use relative units of measurement (%) instead of absolute units of measurement (px). It should also be relatively simple for you to add a 4th or 5th column to your fluid layout. Again it’s the same concepts we’ve already seen. As I’ve done in the previous posts I’ll encourage you to play around with the code here and see what you can do with it. You need to practice making this code do your bidding before you can truly understand how it works We’ll continue this series with hybrid layouts, which we’ll find are also surprisingly familiar to what we’ve already seen.

You are subscribed to email updates from Van SEO Design » Blog To stop receiving these emails, you may unsubscribe now.	Email delivery powered by Google
Google Inc., 20 West Kinzie, Chicago IL USA 60610

iCan't Internet

---

5 Great Places to Find Premium WordPress Themes Posted: 24 May 2011 01:16 AM PDT Many bloggers want their blogs to be user-friendly with features and plugins that will serve their needs for managing their web content while at the same time serving the needs of their readers. If... [[ This is a content summary only. Visit my website for full links, other content, and more! ]]

You are subscribed to email updates from iCan't Internet To stop receiving these emails, you may unsubscribe now.	Email delivery powered by Google
Google Inc., 20 West Kinzie, Chicago IL USA 60610

How Important Is Semantic HTML? | Van SEO Design

---

How Important Is Semantic HTML? Posted: 23 May 2011 05:30 AM PDT We talk all the time about how to better communicate both visually and verbally. We talk about making your aesthetics meaningful and using design principles to help your audience understand your content. What about your code? Can you make the code behind your websites more meaningful? Yes, you can and you do that through the use of semantic html. What Are Semantics Before we get to semantic html we should quickly define semantics. semantics (adj.) of or relating to meaning, especially in language the meaning or relationship of meanings of a sign or set of signs When people say they want to make something more semantic, they simply want to make that thing more meaningful. What is Semantic HTML? Semantic html is using html to reinforce structural meaning. It’s about using tags, class names, and ids that reinforce the meaning of the content within the tags. When content is a paragraph of text you mark it up with paragraph tags. When you have a list of items you use list tags. If there’s some order to the list items you use an ordered list and when the order isn’t important you use an unordered list. Each of the tags mentioned is semantic since they describe the content inside the tag. Semantic html is also about using tags in the right way. A blockquote exists to hold a quote inside, not because some bit of text needs to be indented. How something looks has nothing to do with what it means. It’s why we separate html and css. The former is for structure and meaning, while the latter is for how we present that structure and meaning. Say you write an article with a main heading and several subheadings. You could easily place each of the headings in a div, add a class or id, and style those divs in any way you’d like. We could for example style the following html to visually show our main heading and subheadings: <div class="big-and-bold"> <div class="not-quite-so-big-and-bold"> <div class="small-and-thin"> Visually each of those headings could communicate hierarchy through size and weight. You could clearly communicate the meaning of each heading to your audience through presentation. However anyone or anything viewing the html alone wouldn’t have this meaning communicated to them. Your hierarchy could be inferred by comparing all those divs, but there’s no real hierarchy there. <div class=”big-and-bold”> tells us absolutely nothing meaningful about the content inside the div. It only suggests what the content will look like. An <h1> tag on the other hand clearly says this is the most important heading on the page. This is the top of the hierarchy. Most people, who aren’t web developers, designers or SEOs, probably aren’t going to view your article by looking at your html directly. Since you can visually communicate meaning to your audience why is semantic html important? Why Semantic HTML is Important Semantic html is an additional layer of communication. When you use semantic html you communicate more than when you use non-semantic html. Isn’t that pretty much the point of what we do? Communicate. Real people looking only at how your page displays may never get that additional communication, but machines will. Machines like screen readers and feed readers and search engines. Providing that extra meaning allows those machines to translate the meaning for real people. Semantic html is important because it’s: Clean — It’s easier to read and edit, which saves time and money during maintainence. Imagine adding the non-semantic class=”red” to a span of text. Later you decide that text should be green. That’s going to be confusing to someone editing the html at a later date. Better would be to use something like class=”price” (assuming the content is a price on an ecommerce site). You could then change the color from red to green to blue to orange without confusing what that content is. More accessible — It can be better understood by a greater variety of devices. Those devices can then add their own style and presentation based on what’s best for the device. A screen reader could raise and lower volume to communicate the hierarchy of your h1-h6 tags for example since you’ve clearly indicated a hierarchy. The more meaningful the structure of your content, the better different tools can make use of your content. Search engine friendly — This is still debatable as search engines rank content and not code, but search engines are making greater use of things like microformats to understand content. Google can read the hreview microformat and can use the data to create richer snippets below search results. They could potentially rank pages they know to be reviews higher when someone is specifically searching for a review. I’m sure you’ve seen arguments for why it’s better to use css than tables to layout a website. One reason is semantics. An html table is meant to house data, the kind of stuff you’d place in a spreadsheet. Using table for layout confuses the communication. Just as you wouldn’t create a slide for a presentation by placing images and text in spreadsheet cells you shouldn’t do the same inside html tables. You might have a slide that features data in a spreadsheet, just as you might create a web page that features data in a table, but you wouldn’t try to design every slide using a spreadsheet. Is it OK to Use Non-Semantic HTML? Many would answer no. Some might think I’m crazy for even asking the question. Since semantic html is communicating more than non-semantic html it would seem to make sense to always use semantic html. But are there times when non-semantic html might actually make development easier? Consider css grid frameworks, which typically include class names like grid_1 or container_12. They aren’t semantic. A class name like container_12 indicates a 12 column grid, but what happens later when you want to change the site to a 16 column grid or a 4 column grid. Classes like grid_1 don’t exactly help screen readers or search engines understand content either. They aren’t describing the content. They’re describing the presentation of content. At the same time those class names can be very meaningful to a designer who works with grids. At a glance the underlying grid structure of the design is readily apparent. Grid frameworks generally help speed development time as well so there are benefits to using them. Yet some would say we should never use them because of the lack of semantics Where do we draw the line? Good class names should never need to change, however the presentation of a website sometimes does change. When structure and presentation are mixed as in class=”red” or class=”grid_5″ we have to: Change structure to change presentation Confuse style and structure such as styling class=”red” to be green Leave behind classes in html that are no longer styled at all One solution is to use frameworks like Compass, Scaffold and Sass to convert our non-semantic code to semantic code. Doing so we gain the benefits of working with grid based class names during development and then convert our code to semantic markup for the live site. Like most design decisions there’s always a tradeoff. We have to weigh the good and bad and decide which is best to use for a given project. I’m still mixed on how semantic my code needs to be. All things being equal we should always choose the semantic option, but all things are seldom equal. At times I think the benefits of some non-semantic html as in the grid based class names are worth the loss of semantic meaning. I do think we should strive to write semantic code. I don’t think non-semantic code is as evil as some would suggest. Ask me in 6 months though and I may easily have changed my mind. If you have arguments for or against the use of semantic code please share. Summary Communication is the central task of web designers. Most of the time we think of communication in terms of the words we use and the visuals we create, but it also extends to the code we write. Semantics are about meaning. Writing semantic code means writing more meaningful code. We should strive to write html that describes content and not the presentation of that content. class=”red” is always a bad idea, but what about class=”grid_4″? Is all non-semantic markup bad or is it ok at times and under certain circumstances? My best answer is we should do our best to write semantic code, but we shouldn’t obsess over it. Similar to how we should do our best to write valid code though not worry about an invalid line here or there? Again I haven’t entirely made up mind about this. Where do you stand. Should all code be semantic? Is it ok to be non-semantic at times? What do you consider best practice?

You are subscribed to email updates from Van SEO Design » Blog To stop receiving these emails, you may unsubscribe now.	Email delivery powered by Google
Google Inc., 20 West Kinzie, Chicago IL USA 60610