Beyond Caffeine

In the current technology world, new applications and websites are coming out constantly, and if they aren’t designed to really show people how they work, they often don’t get the acclaim they deserve for what they do. It’s all about highlighting what it important to the people who would use it, and often the sites created by new companies miss the mark.

ExtJS is one of the javascript libraries on a growing list emerging of late, but one thing really makes it stand out - the demos. For most web programmers, often the success or failure of a new language or library is directly related to how appealing its online demonstrations are.

As programmers, we’ve been exposed to more old and new languages, interpreters, libraries, standards sets, software, etc… than we can keep track of anymore. After a while, we tend to give anything new a quick ‘once over’ to see if it grabs our attention. Unfortunately, things that don’t really shine fall by the wayside, and things that glitter tend to do well. That doesn’t necessarily mean that the things that glitter are better than the others, but when it comes down to the few minutes we are willing to devote to analysis of a new language… it has to capture interest quickly. ExtJS 2.0 has some of that sparkle.

It comes down to site design in the end - we want the demos up front and prominent, and the ExtJS site provides that. Right at the top of the main page we have a nice big area that lets us immediately (and visually) understand what ExtJS is designed to do for us. It definitely makes an impact.

We see full out examples of a feed viewer app made with ExtJS, an offline Gears example, a task system made for AIR, a full image organizer, and a web desktop. Then they show us the components themselves: grids, trees, windows, tabs, layouts, forms, and some of the other things we absolutely expect to see when it comes to a new javascript library that is going to be competitive with what we are using. Best of all - in most of the examples we can quickly click a link that shows us the code behind the component.

Of course, we have seen many times before that all the great code in the world isn’t enough for a programmer if you don’t give them documentation or tutorials. A programmer really has no desire to sit down and comb through thousands of lines of code and try to figure out what the person who made it was doing - particularly not when there are competing languages that come with tutorials and full documentation. ExtJS wins again on this mark, having a nice big link that says ‘Learn’ right at the top of the site.

The Learning Section has exactly what most programmers are looking for - an overview, an intro tutorial, a migration guide from other libraries, FAQ, and interactive demos … along with all the regular full documentation and a community forum.

Overall, I think the site was designed with great usability and marketing in mind for the programmer who is the target audience. It’s quick and easy to find exactly what you need to help you decide if this is a library you are interested in. Does it necessarily mean it’s the best library out there? Who knows. Everyone has their preference, but the good construction of the information presented about the library gives ExtJS a fighting chance to shine along with some of the other current big players. Personally it has me interested enough to experiment with a bit to see if it’s going to work for me.

~Nicole

This is a ‘Back to Basics’ sort of article, talking about techniques that we know are good to use, but sometimes forget to implement.

I browse the web on a very fast connection. One might assume that sites load super fast for me. Not really. The amount of times I hit a website that takes forever to load is just ridiculous considering my connection. When you think about the fact that the majority of the world is still on dial-up, I can’t imagine how slow it is for them. (I remember my dial-up days, with much happiness that they are gone.)

One of the biggest culprits I see is the slice-n-dice. You know what I mean, the people who design in Photoshop, and make big chunky slices. Don’t get me wrong, people who are true graphic artists can create beautiful sites, but sometimes those fall in the category I call ‘the prettiest site you never saw.’ Why? Cause it took too long to load and your visitor moved on.

I’m not entirely certain why gradient/logo headers are such a culprit for extra loading time, but they seem to be. I work in web, so within 1 minute on your site I’ve probably checked the code already. It’s just a habit. Anyway, I find ALOT of people who have these big header images that are built of a linear gradient background with a pretty title text. Usually the title text is some sort of unique font, with drop shadows and other stuff.

I see a couple of things happen a lot of the time. Either people just chunk everything in one graphic and save it like that, or they are too afraid of the crop tool to really slim down the gradient. Seriously folks, learn to be merciless with the crop tool, it’s not gonna bite you. Linear gradients are the easiest to crop and the most common on the web.

Let me give you a working example of something I’ve seen a million times.

That’s a sized down version of a 800px (wide) by 200px (high) site header. It has a unique font for the title, with drop shadow and a mild stroke effect. In original form that header is just tossed into the HTML as an image, and has 9.64k chunk of the loading time.

For this very simple header, there is no reason for it to take that much of the load time.

So then, I’ve seen people do the following as an alternative:

They decide to use CSS for the background and cut out the title and put it on top. So they get two images…

A gradient (1.22K) :

And the logo (5.63K) :

They use some HTML like:
<div id="header">
<h1><img src="color-logo.jpg" alt="Website Title." /></h1>
</div>

And some CSS like:

body {margin:0 auto; width:800px;}
div#header {background: rgb(19,75,123) url(gradient-bg.jpg) top left repeat-x; height:200px; text-align:center;}
div#header h1 {padding-top: 90px;}


Which works fine really, as long as:

a) You measure the distance from the top of the logo to the top of the gradient to know how far down the logo needs to be to match the gradient (in this case, note the 90px top padding) … and

b) You don’t mind reworking your title image if you ever change the background. To be honest, I’m a PNG fan, but in this case, using a PNG instead of a color JPG like this would actually create a title graphic double the size.

Okay, so, those two combined take up 6.85K, which is better. But here is where I get on people about not cropping the gradients enough. Why does it need to be that wide? It just repeats. We know this, you are repeating it to make it go the full 800px wide.. so why not make it smaller to start. I see this all the time, and I’m not entirely sure why.

Do not be afraid to crop, and crop some more. Wring every bit of load time out of those images as you can.

Keep the title image made, and then crop your gradient down to 1px on the repeating direction:

If you have a gradient that repeats vertically instead of horizontally - make it 1px high and the full width. There is no reason for it to be any bigger.

So here’s comparison of the how they look in the browser (the top is the full image graphic, the second is the big gradient and separate image title, and the bottom one is the skinny gradient and the separate image title). Remember that this is a scaled down (for the article) version of the actual headers at 800×200px :

For a loading time comparison:

The difference from the 9.64K original all image to the 5.99K mini gradient and logo combo is a savings of 3.65K. Now that may not SEEM like alot, but it’s 1/3 the loading time of the original. If you could decrease all your instances of your gradient use by at least 1/3, wouldn’t it be worth the loading time savings?

So, in a nutshell, my parting words to you are: Crop and Crop Some More!

~Nicole

There is a great article over at UIE.com called "Thinking in the Right Terms: 7 Components for a Successful Web Site Redesign."

Definitely worth a read if you are considering a re-design or handle re-designs for your clients.

(edit: Whoops. It helps if I include the link.)

~Nicole

I have been an adamant Ubuntu supporter since I was ‘converted’ to it - but I have been quite disappointed with Feisty (AKA: Version 7.04). Not Feisty itself, but the process.

I was running the previous version (Edgy) and tried to simply upgrade using the normal upgrade process. While I had no problem upgrading from Dapper to Edgy, I had an enormous problem upgrading from Edgy to Feisty. Part of it was a system issue, and the other part (I assume) was user error.

A week or so ago I tried to upgrade to Feisty from Edgy using the Update Manager (as suggested in the install instructions). However, the update manager kept providing me errors that several file locations could not be reached for download. The update manager would then quit, and I’d have to try again. I assumed this was just a busy server time, but after nearly a week of attempting it, I decided it must be more than that.

I tried editing my sources.list file to go to the generic ubuntu file repository instead of the country specific links, and it started working. Okay, so it’s finally upgrading. Now, there’s this huge notice that tells me not to stop the install or do anything to the computer until it’s done. A challenge to be sure, since it’s very difficult to keep my children away from that computer during the day and it was set to take many hours. Then disaster struck.

With 3 minutes left on the progress meter - it just stopped. For several hours I waited. Wondering if one of my kids had snuck in and touched something. Wondering if the fidgety power issues of my laptop going into suspend while I wasn’t sitting there doing anything had killed it. I still don’t know what caused it, but I do know what happened. Exactly what it said not to let happen - the install was interrupted. The computer frozen, I had no choice but to reboot, cross my fingers, and hope that whatever files were left to be downloaded in that last 3 minutes weren’t vital enough to stop it from loading.

On reboot everything was loading. I watched as the new Feisty logo appeared, the progress bar moving along at a snails pace (nothing new on my slow laptop), then my login box appeared, and it worked. I waited expectantly for the desktop to show up - feeling more and more hopeful that those last few files hadn’t hurt anything. The plain background showed, and then I waited. Waited for the box to appear - you know the one, the one with the little icons that shows what’s loading. The box that shows right before the desktop loads completely. It never came.

At this point, I’m sad to say, I had a bit of a fit. Colorful expletives rolled off my tongue at warp speed, and I even was annoyed enough to threaten my laptop that I was going to do the unthinkable - I told it I would install Windows on it. I even tried to, I’m ashamed to say. But my laptop rebelled against the torture, and continued to crash the new Windows install.

I finally relented in my fury. A couple of days had done some good for my temper and I trotted over to Ubuntu.com to download a fresh copy of Feisty. Now, the Ubuntu site has gotten a nifty fresh look to it, and the download page is quite different (at least from what I remember). I clicked on version I wanted to download, selected my computer type, picked a download location, and did a quick download. I then used my trusty ISO burning software to create an install disk. Then I popped my fresh install disk into the laptop and got ready to make install selections as normal. It loaded up a start page with a bunch of install options. I’m still not sure what the difference was supposed to be between ’start and install’ and ‘install with disk’. Really user un-friendly options. In any event, I tried both of them. They both essentially did the same thing - that is, took forever.

The reason is that regardless of which ‘install’ option I picked, it started to load Ubuntu. Which, on my slow ram-poor laptop, takes at least 20 minutes to load. That’s when I realized something was wrong. Had I downloaded the Live CD on accident? Why was it loading up Ubuntu?? Then I realized there was an ‘Install’ icon on the desktop. I figured, okay, well, maybe if I click on that it will reboot it for install and kill this Live CD. No such luck. My laptop, already pressed to the brink of RAM exhaustion, started to try to load the installer ON THE DESKTOP of the Live CD. After 40 minutes of waiting, and the first graphic of the installer was only partly loaded still, I gave up and shut it off.

I then returned to the download page on Ubuntu to see if there was a non-Live CD install disk I could download.

That’s when I saw it - and then I had another mini explosion. Underneath the ‘Start Download’ button is a checkbox that says this:

Check here if you need the alternate desktop CD. This CD does not include the Live CD, instead it uses a text-based installer.

Talk about non-intuitive and user un-friendly. And by the way - when did the non-Live CD become the ‘alternate’? It used to be the other way around. Getting the Live CD was always an EXTRA option for people who needed to try out the operating system before installing it. I’d like to have a few words with the ‘brilliant mind’ that decided that it should be the default download.

At what point it was decided that a Linux install (historically lightweight to install) should become bloated by a default loading of the full operating system first - is beyond me. I have serious issues with that.

In any event, I went back and downloaded the ‘correct’ version — meaning the one without the Live CD. Then I started the install as normal.

So I’m writing this while it’s installing, and I look over at the laptop and see a bright red screen with a box. The box says:

Installation Step Failed
An installation step failed. You can try to run the failing item again from the menu, or skip it and choose something else. The failing step is: Select and install software.

*sigh* It gave me the option to try again, so I did. Thankfully, it worked like a charm the second time. Now, I have to admit - the install was significantly more simplified than it used to be. Once I got past the irritation I felt about the Live CD thing, I realized that the whole text-based install went a whole lot faster than before and I had less problems getting it all working with everything on the laptop.

When it was done, I loaded it up (much quicker by the way) and it was working very smoothly.

Overall, I’m happy with the result, but the process left much to be desired.

~Nicole

Over time many bad web design ideas have been dropped or lost favour, including unnecessary splash screens and unwieldy framesets, for the good of the web user. However, one web design bad habit that persists is the JavaScript Dynamic Navigation. This is bad news for both web users and those looking to commission a web designer to build a site for them. Ultimately if your navigation is broken, so is your site.

The seven top reasons why you should not use JavaScript Dynamic Navigation are:

Site navigation is difficult when navigation is not permanently displayed.

Everyone likes to know where they are going and even where they are! A site with a permanently visible navigation structure meets both of these requirements, but popup or dynamic navigation systems do not. Remembering that Google and the other search engines are as likely to deliver a visitor to a subpage as they are to your home page, a clear navigation structure is essential. Think of it as they “You are here” icon in your local shopping mall’s map.

Embedded elements can clash with dynamic navigation

A typical dynamic navigation structure will result in an overlay or pop up/down display. The challenge here is that if your site is media rich (ie contains flash animation or embedded video) these embedded elements will take precedence on the page. The end result is that part of your navigation will be hidden behind these elements making site navigation difficult if not impossible.

Cross browser/platform compatibility issues

As any developer will tell you, since the dawn of the internet, not all browsers are created equal. Some applications will follow a stricter implication of JavaScript than others. The only way to combat this issue is through vigorous testing - something that takes time and money. When you consider how quickly some browsers release code updates you have to be prepared to be in constant test and verification mode.

Usability issues- Dynamic Navigation is not for everyone

Just like menus in Windows or OSX, dynamic navigation structures require good hand/eye co-ordination. Not everyone will be as fast or as accurate as you are when it comes to using a mouse and nested dynamic navigation can be particularly hard to use. Usability studies with elderly users or those new to computers and the internet shows that such nested menus quickly cause frustration and are far from easy to use. Operating systems have addressed this issue by allowing a user to navigate using their arrow keys as well as a mouse but this is a complicated and difficult task to accomplish in JavaScript.

The Experts don’t do it

Go and visit your favourite site and then all the big internet names such as Google, Amazon, YouTube, BBC, MSN, Yahoo!, MySpace, eBay, Wikipedia, Craigslist, IMDB, etc, etc. There is a reason that you don’t see these sites using dynamic navigation and that’s because there are better ways. Any coaching or strategy expert will tell you the secret to success is to model those who are already successful. So if th336e experts don’t use dynamic navigation why would you?

You have plenty of other options

One advantage of a dynamic JavaScript navigation structure is that everything is contained in a single script file. Changing any aspect of the whole site’s navigation can be achieved by modifying this one file. However, this benefit is not unique to JavaScript. An external xml navigation structure or a range of server-side scripting processes can achieve the same effect and all are capable of outputting standard XHTML without any of the drawbacks listed in this article.

Your site will be broken if JavaScript is turned off!

With increased security awareness and the constant screen invasion by pop-ups many users restrict or even turn off JavaScript settings in their browsers. While this activity is designed to stop the JavaScript based popups, squeeze pages and floating ads, it will render your site inoperable. Statistics from W3Schools show that 10% of the visitors to your site will have JavaScript disabled. As there are plenty of better alternatives to a dynamic JavaScript navigation structure why even risk alienating 10% of your site visitors?

Written by: Iain Row
About the Author: Iain Row is the lead developer at Prominent Media, Milton Keynes Web Development that specialises in producing website navigation solutions. This article was prepared by Andrew Silvers of Attraction Marketing. 2006 Prominent Media Ltd.

As most people know, IE7 came out in the automatic updates for people across the world not too terribly long ago. While there are some positive things being said about IE7, the bulk of the response seems to indicate that the general user doesn’t like the changes. This is no surprise to usability experts who took a look at the IE7 betas.

IE7 is being repeatedly called ‘user-unfriendly’ and ‘difficult to navigate’. Most of the complaints about IE7 come back to the interface. I remember a long while back on the IE7 blog people were warning of poor usability. That IE7 had changed too many standard layout conventions in the new design, that the control organization for the browser wasn’t intuitive, and even that the color scheme was off and looked more like a combination of several looks thrown together in a blender. Unsurprisingly, Microsoft didn’t make changes to the layout, despite the feedback it received on the poor usability of the browser.

So now that IE7 was auto-installed on many systems, people across the Internet are asking how they can revert to IE6. Doing so is only one of several options you have in dealing with IE7.

If you would like to revert entirely to IE6, there is a discussion on CNET that details instructions on how to do so. In general, it should revert simply by using the Add/Remove programs option.

Yet there are those who prefer to keep the IE7 installed for the security updates, and yet still be able to use IE6 for browsing. If that is what you are trying to do, I suggest one of the two following options to download:

Choice 1) Head over to Evolt and download the IE6 standalone browser.

Choice 2) Go to Tredosoft and download the Multiple IE installer, which will let you choose as many older versions of IE as you would like to install and use.

Another option is simply to leave IE7 as it is, and go fall in love with Firefox or Opera. Hopefully, one of those options will help those people who are interested in using IE6 instead of or alongside IE7.

~Nicole

This is the question I’ve been tossing around with a few people lately, and it seems to be a relatively important thing to consider right now. But before I get into the discussion, let me define what (for these purposes) we’re considering a ‘backend system’:

A backend system:

A content management system (CMS), blogging system, wiki platform, or other general use software system that allows for ease of publication and maintenance. This system is most often database driven, whether via a flat-file database and linked files or a standardized database system (such as MySQL, Access, etc..). A backend system can be home-brewed / designed from scratch, a custom modified package system, or a standard package system.

Given this definition is essentially the perspective to look at this question from - should all new sites be developed with this type of backend involved?

I believe that, when possible, one should always try to develop new sites with a backend system. Why? Well, that’s what I’m going to talk about here.

First of all, the problems discussed by many websites owners are often directly related to a difficulty in updating or changing the website. For example, let’s assume that you create a website for a client that is not tech savvy in the slightest, yet they insist that when it is done they want to maintain it themselves. (If you are new to the web design business, trust me, there are many people out there like that.) What to do in this situation?

Well, you could try to hard-sell them on a maintenance plan, convince them that they are unable to do this on their own, maybe even refuse to create the site with them agreeing to a maintenance plan, and generally make them feel as if they are incompetent. The thing is, I don’t believe that a site -should- be that difficult for them to do basic updates to. Now, if they want to change the entire look of it all from scratch, then yes, they’re very likely out of their range. But adding or updating a link? Adding a current news notice? They should be able to do that.

My perspective is to empower the user, yet I’ll also hear many people disagree with me on this issue as well. I’ve heard web developers talk about how using easy backend systems, and giving their clients the ability to use them for basic updating, cuts into their monthly maintenance fees. I won’t argue that, it does to a degree. However, I think it ends up being of a greater benefit in the long run.

People like to feel like they understand things, aka: no one likes to feel stupid. Empowering your clients in small ways can benefit your reputation significantly. As we know, a large amount of new work for web developers comes from referrals, and making your customer feel good about your service AND themselves in the deal, works out good for you. Wouldn’t you like to hear praise from a referral, for instance something like:
We have seen that you make a good website, but my friend also told me that you also make it really easy to use. That’s what we’re looking for.

So what is the trade-off? How do you compensate for losing a bit of that monthly maintenance fee? Well, to begin with, I’ve already mentioned that creating easy to use sites will absolutely help you in those referrals. New business = more money.

However, let’s talk about some other basics. Let’s say they have a problem using the backend system, you can charge a technical support fee on a per hour basis. Now, that is not license to make the backend system complicated to try to increase those technical support calls. That entirely defeats the goal of more referrals from ease of use.

Next, you can upsell them periodically. Let’s say that you give them a WordPress backend. Were I to do that they would not have full rights access to the plugins or theme areas because those require a bit more technical skill to use and understand. Yet WordPress has thousands of plugins made that add functionality. Send them out a notice, give them a call, and tell them about some new feature you can add to their site and how much it costs for you to add it. A new feature can run them anywhere from a super low installation price of a quote of the day addition, to a more complex install (higher price) of something like a Vanilla web forum for their website that is linked to their WordPress user database.

Overall, you don’t have to lose money, you can just make it in different ways. The added benefit is that while you are doing all this, creating easy to use sites, bettering your reputation, etc… you can very very slowly start charging more for your services. People are often willing to pay a little bit more for something that will be easy for them to use.

Another reason I think it’s a good idea to use backend systems is the concept of distributed content. RSS feeds are an absolute must-have these days, and the great part is that most backend systems include that capability automatically. Additionally, many backend systems have various plugins that can be used with ease, and you can make the site as simple or as complex as you need.

Once upon a time, backend systems were only for the ‘big boys’. The major sites. Huge communities. Now… I think it’s a value added investment for both the developer and the user. The user gets to feel empowered and can update their site easier. The developer gets the benefit of having a much easier time updating and adding features, and the increased potential for referrals.

Beyond that, sites with a backend system are often extremely fast to develop - assuming the developer knows how to use the system well. For my part, I can have a WordPress system installed and running with several plugins added and a few additional themes working within 30 minutes. Compare that to the hours of creating from scratch, and you have a huge benefit in saved time, and that only makes the client happier! Not only did you give them something good and easy to use, but you also did it all really fast! Wow, you really know your stuff While I may say that with a cheeky smile, don’t underestimate the value and effort it takes to truly learn a backend system inside and out. It’s a skill, like anything else. Just like with anything, the better you know the system, the faster you are.

A word of warning: Do not suggest new backend systems that you do not know how to use. That -should- be straightforward, but alot of people run across something that seems ‘cool’ and ‘new’ and decide to try it out on their client. Big mistake. Try it out on yourself. Learn it. What if it isn’t what you thought it was? Never use something on a client site that you haven’t used yourself first. Experiment with new systems, find what you like. Personally I tend to prefer WordPress and Expression Engine for a good deal of things, but that doesn’t mean that those two will suit every situation. You have to keep abreast of new developments in technology, and have fun with it.

~Nicole

While browsing around, InspiringMessages.org caught my eye. I mention it not because it has good code (which it does not), but because it really grabbed my attention immediately.

This site was obviously made by someone who has a natural knack for usability practices. I love (can’t stress that enough) the start page. Talk about clean and simple. People often say, Never use landing pages. This might be an exception to the rule.

Great use of white space throughout the site, simple organization, expected layout and responses. I would like a few section skip links in the left column on the sub-pages, but otherwise each page has little enough content that it makes it clean and simple.

Definitely nice. Plus, I love their banners section and the quotes they use
Overall, great layout. It would be even nicer if they used standard coding for it, but I found it truly inspiring and I might end up using their ‘inspiration’ as a template idea.

~Nicole

Fluid / liquid layouts are definitely considered the ‘ideal’ design type right now, and I can’t agree more. I much prefer a fluid design over a set layout. (Yes, I’m aware that the design for this blog is a fixed layout, I’m getting around to changing it one day, truly. I just procrastinate something awful.)

In any event, whether your website design is a fixed layout or a liquid layout — there should still be a measure of fluidity in text sizing. When I use the phrase text sizing I refer to the fact that users can control the size of text on a page. For instance, they may use the popular CTRL + + to increase, CTRL + - to descrease the text size. Others may use the ability of their mouse scroller to adjust zoom the text size, etc.. While this may seem to be simple, it’s not quite as straightforward as that.

There are often elements, such a section headers or navigation areas, that break when zoomed - meaning they just don’t fit in the space anymore. This can happen in a liquid layout also, believe it or not. Many people use horizontal tab-like navigation, made pretty with images behind it. Now, when zoomed too much, sometimes the text becomes too big for the screen size of the viewer, and in the nature of a liquid layout, the horizontal navigation wraps and continues onto a line below the normal horizontal navigation. In many cases, that can look quite awful. If you use navigation like that, you need to test and see what happens, and design in measures so that if it does wrap - it still can do it in a way that looks good.

For fixed layouts, you get something a bit different - most often that is a horizontal scroll bar in the browser when you run out of room. None of us like those - so its best to test and avoid them if you can.

You cannot account for every possible window size in the world. People will zoom in and out if they know how, it’s like a kids toy, some of them think its just plain neat to see how many zooms they have to do before the site runs into itself. So, how do you accomodate the most people?

My rule of thumb:

Make sure your site can handle two increments both ways (increases in text size, and decreases in text size) without breaking. If you can, then you should be okay.

Here’s an example of me playing with the LovecraftCountry.com forums:

Original:

Zoomed in 2 steps with CTRL++:

Zoomed out 3 steps with CTRL–:

Break = Zoomed in 3 steps with CTRL++:

So, overall… the best suggestion I have is to always toy around with your zoom… your visitors will.

~Nicole

As a web developer, I think that one of the easiest pitfalls to run into is assuming that the content on your page is as interesting to your readers as it is to you. Whether we are talking about features, or tools, or images - adding those things often have us grinning like proud fools and bouncing on our well-flattened computer chairs with a shout of ‘Woot! I’m so good. Everyone is going to love my new [insert some new feature / tool / etc.. here].’

But is that a reality? The answer is, sadly, no. Our happy developer often doesn’t realize that most users not only do not care, but worse, they don’t even notice it. Why is it that a user can visit our page (even multiple times!) and still not notice some new feature we’ve added? The answer is simple - web surfers skim.

Now, most web folks are aware of this habit. Unfortunately, developers often think that the solution to that is to make the text bigger, brighter, underlined, italic, flashing, bouncing, and talking (or, Heaven forbid!, all of the above). Have those same developers sit back and watch a user surf their website, and they are often shocked at how often people flat out ignore those things. Why?

In all its flashing brightness it’s no longer a feature - it’s an annoyance. People tend to visually block out annoyances just like a regular web surfer trains themselves to no longer even see most ads on a page. People tend to block out all annoying things in the same way.

The other reason that a user may not notice is that it depends on what they are visiting your site for. If you are visiting this blog right now, you’ll see multiple post bits on the main page. If you are looking for information on CSS, you will be looking at some keywords that you know. Some other keywords might be styles, rules, selectors, sheets, etc… for things that your experience tells you would typically go along with CSS.

Looking for those things, you skim for those words on the page. However, if you are looking for information on DOM scripting… your keywords would be entirely different. In that case, your primary words might be DOM, DOM 2, and DOM 3 and your keywords might be things like scripting, object model, child, node, etc… for things that you might be looking for with DOM.

What this means to a web developer is that you can never account for what a user is going to see on your page. A web surfer is the epitome of someone who ’sees what they want to see’ rather than all the information. So, to accomodate your visitors, you need to adjust your perspective and realize that you can never fully account for what they are seeing on your page - it will differ from person to person, and even day to day per person depending on what they are looking for.

That understood, let’s consider the problem with most blogs. By default, most blogs are set to show one or more full posts on the main page. This is, inherently, going to make limit what your viewers can actually skim - particularly if you present a main page to them that is the equivalent of about 10 written pages of multiple blog posts. This is often what happens, and you’ll see many blogs like that. The main page is actually about 6 or posts one after another.

If I post 90% of the time on CSS, but my last two posts (shown at the top of the long main page in full) happen to on different topics, a reader can skim through quite a lot of information and think they won’t find what they are looking for on the blog. Not only do those long front pages make for some increased loading time (another deterrant), but if they have to skim down through that much information, chances are good that they won’t choose to. The back button is a lot easier to click. Sure, it works out great if your first post or two are on exactly what you are looking for, but how likely is that? Not very, in my perspective.

So, how do you increase the amount of information they can skim for their keywords on a blog? List your posts instead of displaying them in full. You can just show the title, or you can show a title and a separate summary of the post, or you can do a title with part of the actual post showing. I definitely think that all blogging software should adjust it so that posts are shown in summary form by default, but that’s another discussion. Presenting your information in a more concise way gives the user more possibilities to skim and find what they are looking for that day.

For certain, I can say that WordPress, Blogger, and the Expression Engine all have a default that shows the pages in full (versus a summary), so those are the ones I’ll talk about fixing. I haven’t checked the others, but I’d wager a guess it’s the same in many cases. For now, let me briefly tell you how to fix WordPress, Blogger, and EE.

In WordPress, I think the easiest way to do this is to use the handy little more function.
<!–more–>
All you have to do is type your post as normal, then put this code somewhere in your post (say after your first paragraph or so), and it will stop displaying on your main page at that point, and provide the user with a link to the full post to finish reading it. WordPress also has this button in the post writing GUI. Another option for both WordPress and Expression Engine is to use post summaries (called excerpts in WordPress). For my WordPress blog I use a plugin called ‘Post Teaser’.

Expression Engine makes this similarly easy by the use of a different command in your template code. If you create a post summary for your post, all you have to do is put the {summary} command in your template to show just the summary. For instance, I have some code that looks like this in an EE template:

<h2>In News</h2>
{exp:weblog:entries weblog="news" limit="2" status="open" orderby="date"}
<h3><a href="{title_permalink="news/article"}">{title}</a></h3>
{summary}
{/exp:weblog:entries}

Blogger is a bit more complicated, unfortunately. It involves making some changes to the stylesheet, and turning on a feature called permalinks (which I think should be on by default anyway). There is a very good explanation of how to create those summaries here: Expandable Post Summaries.

I think that most people will be able to get more use out of a website if they have more summarized information to look at. Keeping it short and making your content clear is one of the laws of good usability. If you want to learn more on usability, there is a very good (and short!) book by Steve Krug called “Don’t Make Me Think” that does a great job of teaching the basics of usability.

~Nicole