Site Design
From KallestadWiki
I'm currently in the process of revitalizing all of my site design efforts (for many sites) so that I can come up with a manageable plan for everything - from the underlying codebase to the displayed HTML and CSS.
The first part of that effort is understanding that which must be created at a fundamental level. Rather than attack each site design as an independent effort, I would prefer to have a standard methodology and a base design from which I can grow and develop unique elements.
Contents |
Elements of a good web page
Here's a starting point off the top of my head:
- Accessible (via screen readers, etc.)
- Clarity of purpose
- Intuitive Navigation
- Low time-to-load
- Readable
- Consistent cross-browser/cross-platform appearance
- Elements peripheral to displayed content are inobtrusive
- Smooth degradation for unpopular browsers
More on the subject here.
What I want to display
Before understanding the templates that need to be developed, I must understand what it is that I want to display to the reader.
First let's talk about the major elements:
- Blog/Journal - readable and simple - the design should not be too distracting
- Wiki - Editable end-user developed areas
- Forum - Discussion area preferably linked and integrated with other site areas
- Code - Be able to display code snippets as needed without stretching it into whitespace
- Maps - Geographic representation of data sets
- Videos - mostly YouTube kind of things
- Graphs - when there is data that needs to be graphed
- Tools - mostly form based utilities that require interaction on the part of an end user to provide useful results
Tools to do the job
Performance
Javascript
I've spent the majority of the last two years examining performance. A lot of nifty features require javascript, but that's what they are - nifty features. The heart of what anybody wants to examine is the textual content of a given web site. Sure, pictures sometimes make things easier to read, and reasonable interactivity does require some sort of scripting, but for every necessary piece of the puzzle there are always unnecessary pieces.
One thing I've come to realize is that compression is bad. It decreases page load times for first time visitors, but repeat visits are desirable and necessary, and compression implies performance degradation for repeat visitors. Lighter coding and strong cache techniques are more desirable, as is a clear separation of scripting responsibilities.
For instance - one road I went down to increase performance was to come up with a site-wide javascript file that covered all situations. It worked well, but the downfall is that it required a memory footprint that was unacceptable for many pages because things like lightboxes and WYSIWYG editors simply are not required on most pages. With strong cache techniques coupled with a clear segmentation of code responsibility, you can separate out the responsibilities and have appropriate scripts only load on appropriate pages. The scripts will only have to be downloaded once for most clients and when they do run into pages that require them, end users will only download that which is necessary to interact with the information they are currently looking at.
Sometimes that means a page will require 6 separate javascript downloads, but pages with that much interactivity will be viewed only by people who want to interact, and the delay in fully loading the page will be acceptable and it should be a one time thing.
Multiple small files, appropriate cache headers, and a web server designed to push small static files out quickly is the best road map for solid performance.
CSS
Now that we have javascript taken care of, let's touch base on CSS. CSS is still very much a touch and go game. Hacks for certain browsers are required all over the place. The best antidote for thick and multiple CSS files is a simple site design. Along the lines of what I had to say about javascript - cache techniques and multiple small functionality segmented CSS files are the way to go. Rounded corners are not performance friendly. They imply markup what is overly verbose, a long set of images, and they take entirely too much time to get straight for all browsers on all platforms. Things like transparent PNGs and .htc files? As far as I'm concerned, if IE can't do what we need it to, then it should be considered a degraded browser and fall back to a less elegant but equally effective solution.
Images
As far as images are concerned - I've gone back and forth. I think as long as you utilize markup that is explicit as far as the size of images, you should feel free to use as many images as are necessary to a design. It's a grey area and a slippery slope, but it is what it is. Always pay attention to image size and quality.
HTML
Now lets talk turkey with templated html - the wrapper stuff. In the end, we will be working with a wide variety of layouts, but navigational elements should be consistent and simple. I've fallen victim to CSS/Javascript based menus. That's no good. If you can't slim down your site to a defined set of 5 major categories and branch out from there for detailed listings, then you have a serious lack of focus.
SEO
SEO is search engine optimization. The problem with considering SEO only in an internet perspective is that you are taking a very small piece of the puzzle to focus on. We're not just talking google, but any sort of site search functionality that you want to implement, and the very real possibility of search ranking on niche search engines that would deliver a much better visitor.
As far as the major SE's go - they will take care of themselves as long as whatever site is marketed well. Just follow a basic set of guidelines, follow standards as much as possible, and advertise. It's as simple as that. And you thought it was voodoo.
Basic elements are all that I'm talking about. Keep the meat of the information as close to the top as possible. Use various techniques to ensure that the importance of important pages is readily transparent, and push templated and generated information towards the bottom of the page.
Layout
I've been looking into various layout options and reading books with at least a peripheral focus on web navigation. I've also been considering the perspective of search engine spiders. One thing that stands out from a usability perspective is that most pages should have a similar look and feel, so that the brand of a particular web site is apparent.
I'm of the opinion that the home page should be more of a portal. Web sites should be structured in such a way that there are tiers of information - the top level tiers focus on the types of information being presented. Mid-level tiers and below should provide categorized links to either more specific or less specific information within each top level tier. There can and should be cross referential information embedded within the detail of the presentation layer. Expected links for things like "About", "Search", RSS Feeds, etc. should appear in the footer so that they are readily accessible from any given page, but care should be taken to ensure that those pages do not detract from the overall theme of the site.
The home page is a different entity all together. It certainly should contain links to top-level tiers and those links should obviously carry a certain amount of weight. Information should be presented that represents the current state of a site - from the most recent information, to the most effective ways to get at the information end users are seeking. In an ideal world, the home page would not be dynamic, at least not on user request. It could be regenerated with regularity, or have very simple dynamic foundations, but performance on the home page is key. The home page is the website brand.
Considering all of this, I feel it is important to have several different layout options for publishing - ones that can be selected on a page by page basis when publishing. Ideally, you would want all of your pages to have the same layout, but the fact remains that certain layouts are appropriate for publishing certain kinds of information, and no one particular layout is universally applicable.
We need to look at things from three perspectives:
- Navigation Layout
- Visual Layout of various page types
- Weighted Layout
Navigation Layout
Where navigation is concerned, we have several types of links to consider:
- Top Level navigation links (Main categories)
- Site information links (About Us, RSS, Search)
- Helpful links that explain or assist in navigating the site
- Related content links
- in and outbound
- End User generated links
- Authoritative links
- Revenue generating links
- Null links
- Multi-page links
- Links which have an inherent level of importance
- Named Anchors
The real question is where do all of these links belong. Should we template the links? Do they belong directly in the content, in the sidebar, in the footer? Do these links need to be highlighted? Do they look different? Are they structured differently? Can they be static? What about pseudo-static?
Visual Layout
Visual layout really gets me thinking. I think about my iPhone, my old windows mobile device, people using browsers that are not the most current or popular, and I also think about all those people with wide screens, big monitors, dual monitors, other high resolution devices, and high bandwidth connections paying the price for all those dial-up users with 800x600 screens.
I think that the best solution would be to have a common and simple layout as a default, but provide the capability for end users to take full advantage of their systems. From a design perspective, this means a LOT of work, several different layouts, and conscious decision making when publishing which can turn into automated decision making in the future. (i.e. we don't want to publish a page to the iPhone where it's main element is flash-based, we want to publish it's html based alternative).
Before I get into a discussion on how to track which layout we are presenting, I think we should decide on a base layout and go from there.
Home Page
I think the home page design will change based on the product being produced, but let's take a look at several well laid out examples that are out there.
- I really like the idea laid out at Electrolysis by Tami
It looks like a magazine, which correlates well to a site that regularly publishes articles, but not one that is updated daily - perhaps a weekly or a monthly site. The biggest problem with this kind of a home page is that it has a large image to download, but on a high speed connection, load times are very speedy.
- Google is another good example, although their page has gotten more and more weighty over the years.
The key here is simplicity, and access to a variety of highly weighted features through the home page. Your most likely desination is very prominent, and there is room for a festive update with very little change to the page.
- The Grow Collective home page caught my attention a while back. It has expanded as well over time, but I like the way that there is a clear separation of major visual elements that catch your attention. Unfortunately, I'm not super-keen on the implementation because "About Us" is focused more prominently than their actual content.
- I also like the look of the sparkplug home page. The pictures are nice, small, and capture your attention because they are interesting. I like that the major navigation points are prominent, but like Google, they seem to have a lot of well placed clutter.
- Created 201 has a very unique home page. Very thin, very visually appealing, but it's flash. The same thing could be done using an image map, however.
Much like google, their brand name is easily recognizable in a thumbshot. Interesting.
The thing that strikes me most about the home pages I've selected as examples is that all but one contains visual elements that are quite weighty. I like the use of open space. I like the simplistic design. I like easy to recognize navigation elements.
What is most interesting here, to me, is that most of these sites do not show article snippets or really give a clue as to how deep their sites really are right off the bat. None of these sites are "daily visit" sites, and more often, I would think links and bookmarks would be to deep pages within the sites.
Daily visit sites are typically not very visually appealing, but instead rely on content to draw visitors back with frequency. It occurs to me that the best solution would be a well branded and well designed home page, with a sub page easily navigable off of the home page that contained targetted information to bring back repeat visitors. That way, you could have a blog page, a news page, a discussion area, etc. that brought back repeat visitors to the area that was most desirable to them, and have continuing cross-linking to other areas that may be of occasional interest to the general audience.
Another common element I recognize among these sites is that they are all friendly to smaller screens, but I have a clear preference (in my mind, not in this text) for those that use whitespace to define their focus area rather than those that choose to use clearly defined borders. Borders make me feel like I am constrained to a small area. Whitespace makes me feel more free.
Blog / Article Pages
I've spent a lot of time looking into this and I have some background information to provide.
I read a study a while back, by Jakob Nielsen (hope I spelled that right) which showed that people focused more attention on smaller text. This is a big reason for blogs and portal pages like CNN having small text associated with their articles. I don't know that I trust the results of this study because it seems to me that people would spend more time looking at smaller text because it is harder to read. In fact, I would go so far as to say that heat maps in general are not very helpful because their results are always skewed by the content being analyzed by the end user.
Another item I've read that is very key to article focused sites is that serif'ed fonts (i.e. Times New Roman) are designed specifically for reading a large amount of text. I think that this particular aspect deserves a little bit more research, because although non-serif'ed fonts like Arial are designed for headers, the popularity of Arial's use with MS Word documents may have simply changed the preference for non-serif'ed fonts to the masses.
Speaking of fonts, even though many fonts are available widely, not all of them look good on widescreen laptops. IE7, Windows Vista, and Windows XP seem to have different behaviors as far as web based fonts are concerned. It's best to stick with the basics, and to use image replacement (rather than sIFR) where other fonts are required or desirable.
Now that we've gotten that out of the way, let's talk sidebars. Sidebars conceptually are great, but in practice, they seem to get ignored by end users en masse. While I really like the idea of having a nice looking menu in the sidebar for related topics, ads, or other contextually relevant content, the fact is that end users become blind to sidebars much like they become blind to banner ads. I'm not saying that sidebars are not useful, but I am saying that they are only useful for very simple navigation, and if they are being used, alternative navigation should be available. While some users eyes will be drawn to the sidebar to get back to the main topics or to tree-navigate a site, most users are simply blind to that portion of the screen. It's funny, because from a webmasters point of view, I never would have guessed this to be true, but I have communicated with a lot of people on the subject, and while I have no imperial scientific evidence, the results of my personal inquiries are enough that I am swayed.
Further on the subject of sidebars - I have a preference for right aligned sidebars because contextually, they end up below the main content area. The problem with a right aligned sidebar is that you end up with width restrictions for your content that are sometimes difficult to manage. CSS Floats can be utilized to have a left-aligned sidebar that is contextually located after the main content. Sidebars seem most useful for two things IMO:
- Providing a base element for your color scheme
- Thinning out an article so that it appears longer than it is
The thinning out isn't necessarily a bad thing. Looking through a series of pages, I can see where a full-width page could look annoyingly small, but the content is actually important. Conversely, looking at pages like this one, having the content thinned out simply isn't appropriate. So... how to have my cake and eat it to. That is the question.
After 3 1/2 minutes of thought on the issue - I can think of a way to address the issue. First - no visual indication of a right side border - simply use a layout constraint. Second, for content that deserves or needs to be wider, put it in a container that can stretch over the right border when necessary. The caveat would be that the centering would be based on the main container. I guess that's a good thing.
I started a little bit of work on these layouts.
Discussion Pages
If there's one thing I don't like about interaction pages on the web today, it's everything. I don't like the way they look. I don't like the way they perform interaction. I don't like the basic design concepts. I don't like that people can't seem to come up with a happy solution for threaded vs. linear layouts. There's way too much in-the-box thinking.
Getting down to basics, what people really want to read is the content. Strip down the condiments and stick with just the meat.
Weighted Layout
Where weighted layout is concerned, we want our most important pages to be apparent to both search engines and to people. We want our most recently published pages to be spidered quickly so that they are available to the search engines quickly. It seems to me that the dynamic changes on most actively developed sites with regularity - a page that is important today may not be as important tomorrow or next week or next month. In this regard, we have to have some dynamics in place that will highlight page importance again to both end users and search engines. It needs to be done in such a way that we can leverage our existing strength to make some pages important manually in certain cases, but also in a way that we don't have to even think about it.
Looking at how this occurs naturally in the wild, I see that many CMS-ish systems have an automated structure such that it's easy to find most recently updated information. I think this is a solid foundation, but when I think of sites with multiple active CMS-ish systems - forums, wikis, blogs, etc. - having separate "recent update" systems can tend to push the weight and importance of active areas of the site away from the site's main focus. Further, a single page that is updated with frequency would always hold a certain amount of importance whether or not it is actually important to a site.
