Cold layout
From KallestadWiki
Contents |
Layout Basics
After having some CSS issues, I decided that a step back was needed. First I need to define the areas of the screen that I want to address. For each area, I need basic layout information.
Once I have that information, I can go into each area and define stylings and functionality a little bit further.
Main Layout
For the main layout, I wanted to take advantage of whitespace defined areas as much as possible. Rather than have defined borders, I think it's easier to let whitespace define the regions within the page than to have defined borders. This alleviates decisions regarding rounded or square corners, the styling of borders and it also relieves me of a lot of hassle regarding box model problems accross various browsers. It also keeps the page as a whole less busy, and leaves things loosely defined enough such that if I ever have problems with text wrapping, they should be minimal.I played with liquid layout options, but because IE has issues defining arbitrary widths for elements, I chose to go with a fixed width model.
Though there are 8 areas defined, the HTML code should be free from too many extraneous wrapper elements - at least for the main layout template. The sidebar on the right will remain blank, so it does not necessarily need to be defined. The two background elements may be able to be contained within the existing layout elements without the need for specifically defined regions for their code. Regardless of how the markup ends up looking, let's review the basic page elements:
- Top Background - defined width 330px
- Bottom Background - defined width 330px
These two elements provide a visual guideline for following the page alignment. It's very subliminally effective.
- Site Navigation - width 660px
- Sidebar - width 120px
- blank sidebar - width 120px
The site navigation does not necessarily need the fully defined width - the important thing is that it is justified just to the right of the background image. In fact, the content should be defined such that the user can increase the text size by at least two levels using firefox without any wrapping occurring, but that's a font issue to be addressed shortly.
The sidebars, one blank and one content bearing thin out the page to a degree - making the content look a little bit more full, but also providing the visitor with some useful information.
- Page Info / Site Info - width 550px
I thought about this over and over and over again. I don't want a footer littered with little images nobody pays attention to. I don't want a lot of links within any given page that are not necessarily useful. I don't want to distract from the main content in a potentially thin page. Footer links almost never get clicked in my experience. When they do get clicked, it's because somebody is either looking for information about the page, information about the site, or to provide feedback in one form or another. I think the best way to deal with this is to provide a small set of clearly defined links.
Again, the width isn't so much an issue for this element as long as it doesn't overlap with either the sidebar or the background image.
- Main Content - width 760px
- Pullquote - width 160px
The Main Content area and the pullquote area are the two most important and reader sensitive areas of the page. The pullquote does a good job of pulling away any "boxy" feel that the page has by crossing an arbitrarily defined border. It's prominent location will pull the user's eyes directly towards this area when visiting the page. The main content area is where the meat of the page resides.
Main Content Area
The main content area can be broken down into several regions, each with a specific task in mind. Width is not so much a factor here. We are already working within a defined region, so things should pretty much lay themselves out in logical order. Multi-page links are a must, but the basic 1,2,3 kind of thing isn't desirable since the pages are templated. Unique titles displayed in the multi-page link area where appropriate is a good idea.The advertisement area goes where it should - directly at the user's eye level when they are at a point where they are concentrating on the page. It also splits up areas of content while still remaining relevant within the page.
I've gone back and forth with related links and determining the most useful and effective way to present them to the end user. There are on site related links and off site related links, advertising links, discussion links, authoritative links, and sometimes you just want to put a helpful link up there. I've thought about separating the link types into their designated areas, but that tends to leave such links in a blind state. Like ads, users tend to become blind to defined regions within a given page. What I finally decided on is that all related links should be grouped together in a useful and commonly read area, defined by link text and surrounding text. The link region should fall underneath advertising, and it should in general be populated on every page.
For the script based link area, I was thinking along the lines of links for bookmarking the page, voting for the page, changing text size, and other similar useful, but not necessarily page-exiting links.
The pullquote area is optional, and when populated should float 80 pixels inside the main region and 80 pixels outside the main region. This could be replaced by an image, or alternatively, a left floating image can remain within the article along with the pullquote. A fixed width region makes this a lot easier to deal with, as less popular browsers should render the page along close enough lines that the overall vision and layout of the page remains the same.
Styling
Now that I have defined regions to work with, other styling information can be laid out logically.
Fonts
One thing that has become clear through my experience of web design - you don't want to have too many fonts on a page. First you don't know what fonts are supported on the end user machine, and second, too many fonts can distract from the layout and purpose of a page.
What I have decided is that all Title-ish and header-ish fonts should be an Arial sans-serif kind of font. All article-ish paragraph-ish text should be a Georgia/Times serif'ed font, and all code snippets should be a monospaced courier kind of font.
IE's tendency to use 120DPI fonts on widescreen laptops is a bit of a concern. It could potentially throw the layout off, and it could make the page render in a manner such that the visitor does not want to come back. The only way I can see around this issue is to have a font-resizing utility on page, or potentially a fly-in that explains the ctrl+/ctrl- function built in to change the font sizes of web pages.
The other issue having to do with fonts is the line spacing. Line spacing differences between browsers coupled with the fact that browsers render fonts differently than one another in general means that we can't have a single layout that is exactly the same in all browsers. For this reason, we can't arbitrarily define a fixed height for most elements, and font sizing has to be close enough such that an overal increase in font size at the browser level will not harm the layout in general.
Blocks
Padding and margin come into play in most layouts, but for this layout, pixel alignment is not entirely necessary and the primary concern is that we don't have text overflowing from one region to another. Thin padding and margin settings are in order.
Styles that need to be defined
With arbitrary content being populated, the best way to maintain consistency with look and feel is to pre-define a set of classes that make out the potential layout of a page.
- list items - definition lists, ordered and unordered lists
- images - floating left, right, center, bordered and captioned, and stranded
- headers
- videos
- quotes
- code blocks
- highlighted regions - two or three potential possibilities
- nofollow links
- paragraphs
- tables
- advertising
- highlighted text
List items
I actually very much like the MediaWiki list items - square bullets with a light / low contrast color. I think I'll add a hover highlight just for fun, and of course, just for browsers that support li:hover actions. Sorry IE fans. For numerics, really the only consideration is the type of numeric - and I think decimal notation is the most intuitive to follow.
Definition lists is a whole different ball game. I'll come back to this later.
Images
For images, MediaWiki is a great example of well thought out styling again. The images are actually wrapped in an unobtrusive box, with strong borders along the image and light borders with the surrounding page. Their is an easy link directly to the image, and an easy to follow caption underneath the image.
I would like to have a javascript applet potentially load the image onto the screen and display the full sized image along with copyright information or other information about the image on page. Images should always link to an informative page about the image.
Centered images should have no surrounding text wrapping. Floated left and right images should have text wrapped appropriately.
Headers
The H1 header is really the on page title of the page. There should only be one H1 header per page. Sub headers - from h2 to h4 should decrease in size from the H1 header gradually, so as to declare their decreasing prominence. H1 and H2 should have clearly defined areas, whereas h3 and h4 will not. h5 and beyond should only be declared within the template and will be styled accordingly if they are necessary. h4 should be nominally larger than normal text, and h2 through h4 should be bold text, arial font.
videos
Much like images, videos should be bordered unobtrusively, and likely this will include more html code than just css declarations.
quotes
quotes can be wrapped in the blockquote tag, but again there is wrapper markup to consider. The quote should spell out the source of the quote plainly, and the reference should be included in the page information, along with an archived copy of the original source, if applicable.
code blocks
code blocks generally involve syntax highlighting. Syntax highlighting in html is extremely verbose, the css stylings are equally verbose. For this reason, only a simple styling should be included in the main CSS declaration, and really just so the <pre> and <code> elements can be utilized for something akin to code blocking, and not necessarily code blocking.
Preformatted text (<pre>) should be formatted slightly differently than declared code elements (<code>). Code can be wrapped and indented. Preformatted text cannot be.
I also may have to deal with the fact that <pre> and <code> don't always get the job done. Sometimes we want something that looks monospaced and textually formatted, but within that region we need to lay out other html.
highlighted regions
Quotes and Codeblocks are one kind of highlighting. We potentially have more highlighting that needs to get done.
nofollow links
User submitted links that have not been reviewed should be highlighted to warn the end user. Maybe highlighted in red, maybe faded, but definitely highlighted.
paragraphs
Paragraphs and other body text need clearly defined padding and margins. Aside from that, we need to consider line height.
tables
Tables can be used for many different things, so we need to consider the various uses and make tables available accordingly.
- invisible layout assistance
- spreadsheet style demarcation with headers on the top, the left, both, or none
Advertising
Advertising should be held within a container with a defined height and width, so the layout of a given page can be spelled out prior to the advertisement actually loading. It should be clearly marked as advertising so that people don't inadvertently click on ads and have a bad experience, and also so that when an ad does not load, the end user does not feel like he or she is missing out on something.
Other Types of Pages
This layout is fine for blog and article kinds of pages, but what about different layouts?
The layout, I think, is fine for most types of pages. There are some types of pages - maps for example, that require more end user on screen interaction and require a full width layout. This layout is actually pretty simple to modify for full screen width layouts, and it should keep with the theme pretty closely.
Other layouts have more to do with styling the main content area than anything else. Multi-column layouts within the main content area, styled discussions, etc. can all be placed within this layout. As much as possible, I want to stay within the same basic structure - both for consistency all around the site, and for a decently reproduced printable area for my print media stylesheet.
