So you've decided you need a website? But, where do you start? We have found that most people don't know how to prepare for the initial meeting with their web designer. However, if you can take a couple of hours in front of a computer with a pad and paper, the amount of time and money you will save is amazing. Below is a list of questions to consider:

What Do You Want Your Site To Do?

When beginning a web project, it's a good idea to sit down prior to the initial meeting and figure out exactly what you want from your website. Focus your thoughts on the most important thing: your visitors. Who will be visiting and what will they want to see when they arrive. A fantastic exercise to do while completing these steps is to ask either a current client or one that could be interested in your services. Sometimes your potential customers want things you've never thought of.

Most people simply want a small site to display a bit of information about their company and its abilities in an aesthetic design. However, there is so much more your website can do for you. Would you like it to keep track of prospective customers? Would you like to offer online coupons? Would you like to supply industry-specific articles that will showcase your expertise and give you credibility? Do you want an online-only promotion? Do you want to write a blog to gather subscribers who are interested in your knowledge?

There are so many things a site can do and so many ways it can communicate with your visitors, even outside of business hours or when you're not there. Take a few minutes and write down what you want your site to accomplish.

Do You Have Any Repetitive Tasks?

Another great thing your website can do for you is eliminate repetitive or mundane tasks. Whether you're a chiropractor who constantly has to give directions to your place of business or a landscaper who provides a list of land-care tips, you can use your website to communicate these. Think about what your customers will want. What can you offer online so you don’t have to provide it in person or on the phone? This will make your website work for you and free up your time.

Do You Already Have Existing Marketing?

Marketing must be congruent. Your website must match the branding elements of your signage, vehicles, business cards, letterheads, brochures, etc. If these elements are different, it causes confusion and dilutes your message and your memorability. Take a look at your current investments in marketing and consider matching what you already have. If you decide you want to start from scratch, realize there will be up-front costs to changing other elements of your brand.

What is Your Competition Doing?

An excellent exercise, before you put money into your own website, is to see what your competitors’ websites are doing. If you have specific competitors that you know by name, visit their sites with a neutral mind. Write out your thoughts and feelings about them. Is their web presence helping or hindering their business? What do you like about what they're doing? What do you dislike? If you don't know any competitors by name, do a Google search for your industry and your city (ex. "Florists Calgary") and check out the first few pages of links until you find several actual business websites. This is often the most valuable use of your time; things you can do better than the competition will become obvious.

What Do You Like? What Do You Dislike?

Then, expand your search to outside your industry. Find five favourite sites and five least favourites. List specific things for each address (ex. "I like the logo placement," "I dislike the darkness of the site," "The amount of helpful, free content builds their reputation excellently,” "the font size is too small," etc.). This is an invaluable tool you can take to a web developer.

Going through these questions is an excellent way to prepare for your initial meeting. From our experience, if you answer them all, you will be more prepared than 90% of people out there looking for a new site. It's an hour or two well spent and will save you a lot of time and money.

YouTube Turns Five

Well, last week, an already iconic Internet website hit its fifth birthday. YouTube, founded in February, 2005 had its first video posted on April 23, the same year. Nineteen months later, Google bought YouTube in a 1.65 billion dollar deal showing how critical a need it met in the marketplace. Today, it is the third most visited site on the Internet according to Alexa.com. In a business context, this is valuable information to know because if you are in an industry where online video would be useful to your potential customers, your videos are accessible to an enormous 100 million visitors each month, for free. Is it time to consider if you should have video content on YouTube?

Some other interesting facts about YouTube:

1. An average of 24 hours of video is uploaded to YouTube each minute
2. This is content equal to 150,000 feature length films every week (or 118 years of video each month)
3. YouTube is the third most visited site in the world according to Alexa.com (first is Google, followed by Facebook)
4. YouTube was created by three former PayPal employees
5. Google paid $1.65 billion for the site 19 months after it went live. There is approximately 570 days in 19 months meaning that the value of YouTube grew by almost $2.9 million per day.
6. In August, 2008, YouTube surpassed Yahoo! As the #2 search engine on the net.
7. 77% of users who visit YouTube intend to watch only one video, but end up watching more

Developer Tips for Designers: Scaling & Gradients

There was once a time when I spent equal time designing and developing. Nowadays though, I'm almost 100% developer and the designs come to me (by some unholy magic I assume). In a lot of ways it's nice to be able to focus on developing and let someone else be creative with the visuals. Coming from both a design and development background has it's advantages though; developers are the guys who's job it is to turn great designs into standardized web compliant code and we have knack for spotting bottlenecks in design. Our unique perspective gives us an uncanny ability to predict if a design will translate into a slow loading page or if it'll have problems scaling. If all designers were also developers (with a wicked visual arts talent) we'd be a little closer to world peace... or at least "office peace". This is unrealistic, but teaching designers some key developer concepts is totally doable and is what I'll attempt to do in this article.

I'll be focusing on two common bottlenecks in web design: gradients and scaling. These two are not necessary independent issues and can overlap (chuckle). Inside joke revealed when one finishes reading this article.

Scaling

It would be pretty strange if Picasso's canvas suddenly grew ten times taller or shrank to half the height whilst he was in the middle of painting Three Musicians. But that's exactly what happens on the web. Our canvas is the browser and that browser can look a hundred different ways on a hundred different computers. (Actually, it's more like billions of computers and a plethora, but you get the idea.) Interestingly enough there are still designers who are oblivious to this. Don't worry designers, I'm not going to slap you on the wrist, you're already on the right track if you're reading this article. Consider these statistics for browser resolutions over the last decade. (Taken from w3schools.com )

Date	Higher	1024x768	800x600	640x480	Unknown
January 2009	57%	36%	4%	0%	3%
January 2008	38%	48%	8%	0%	6%
January 2007	26%	54%	14%	0%	6%
January 2006	17%	57%	20%	0%	6%
January 2005	12%	53%	30%	0%	5%
January 2004	10%	47%	37%	1%	5%
January 2003	6%	40%	47%	2%	5%
January 2002	6%	34%	52%	3%	5%
January 2001	5%	29%	55%	6%	5%
January 2000	4%	25%	56%	11%	4%

According to this data, the current trend points to most users using displays set to 1024x768 pixels or higher. What's interesting to notice though is not too many years ago, 800x600 pixels was the De facto. Even though the current trend is a large majority, it's important to consider that minority with lower resolutions. How important are these people to you? If you're demographic is the elderly or visual impaired, then that number is very important to you as they constitute for most of the minority. On the flip side, what might you're design look like in ultra-high resolutions; maybe it's difficult to read text or your non-repeating background exposes some details that would otherwise be hidden at lower resolutions. To be extra sure that you’re designing with your demographic in mind, you’ll want to pay attention to your own demographic statistics instead of relying on generic web stats. If you’re designing for a brand new site, you may not have the benefit of visitor statistics and may have to rely on what you know about your audience already, or keep general best practices in mind. If you’re designing for a site that has been around for a while, take a look at the resolution statistics being used by your visitors. If you don’t have this data available, talk with Intoria about setting up an SEO starter kit on your site so that over time you’ll be armed with tons of visitor and traffic information that you can use in improving your site.

Equally important is what portion of the design will users experience without scrolling. By it's very design, content on the web is meant to be experienced from top to bottom and content that extends past the vertical resolution of the screen is accessed by scrolling down. Important content should exist in this top portion that is visible without scrolling. This "top portion" or "sweet spot" is equal to the height of our minimum resolution demographic as determined by the designer. For example, if we've determined a large portion of our audience will be entering our site at 800x600 pixels then our sweet spot is 550 pixels from the top our our design. This is taking into account that browser UI occupies some of that space as well.

Most designers don't throw together web designs that are 3000 pixels tall, usually they're the height of standard monitor's resolution. Sometimes these designs incorporate elaborate graphics on the header and footer that when 600 pixels apart look great but when 3000 pixels apart start looking out of place or loose their balance. It's important to stay away from relying on visual balance between elements that may be separated when a page grows. It is also important consider what a page might look like with very little content - when it shrinks. It's not as common, but sometime a client will request a page with a single line of text or more commonly a page that displays a 404 error situated nicely within your design. Instead of being too distant, these situations can create opportunities for elements to collide. In such a situation elements will pass over or under one another in respect to their position in the z-index stack. Alternatively colliding elements may stop a design from collapsing and create unwanted whitespace.

Gradients

Gradients will almost always translate into a repeating background and it is important that they do for the sake of speed. With respect to loading times, it is never economical to load large images, especially images that incorporate gradients since they posses more colours and therefore translate into larger file sizes.

To illustrate a common issue with gradients lets image a page design with a background that is a repeating horizontal gradient. In Photoshop, this design looks real good, but when we start populating it with real world content suddenly things aren't so pretty. For starters, all images within the content now have sharp borders; whereas with a solid background colour, images with the same background colour could blend seamlessly. Now, things would look a lot better if we used transparent .png's, but seeing how Internet Explorer 6 (which does not support transparent .png's) still constitutes for a significant audience this may not be an option for you. Alternatively we could use transparent .gif's, but these too are not ideal as they often leave annoying artifacts along the edges. The best solution is to imagine what your content might look like on top of your gradient - If you don't like how it looks, consider adding a solid background to you content block and have the gradient fall behind that. Again, this is a design issue and designers need to be making these decisions, not developers.

Let's also imagine a design that has a vertical gradient at the top, starting from black and then transitioning into white for the body of the design. But wait, there's more. At the bottom of the design there is another gradient transitioning from the white body colour to a royal blue. The desired effect is achieved when the design is 600 pixels or more tall, any smaller than this the two gradients begin to collide and suddenly what was intended to be a soft transition is now quite the opposite. See figures A and B.



This can be avoided in development with minimum height restrictions BUT it is most important that designers be made aware of this when attempting to create fluid designs. It is a designer's responsibility to express such restrictions to developers. Far too often developers are faced with making these types of design decisions later in development because designers haven't described the intended scale limits of their design.

Hopefully someone has been enlightened by this article. At the very least, I hope that designers have some sense of the dilemma developers sometimes face with their designs. Developers should not be making design decisions and designers need to define the boundaries which help them maintain design control over brands their creating.

For any artist it is essential to learn your medium and in the case of the web the medium is the browser. Imagine your designs as dynamic interactive art. Consider that your audience is constantly touching, moving, scaling, and playing with it. Think about how your canvas changes and how the environment effects the appearance of your design.

What we've learned

1. Your minimum resolution is of maximum importance.
2. Make sure the main elements of your design fall inside the "sweet spot," but give attention to what's "below the fold" as well.
3. A painters canvas doesn't change shape or size, but yours does. Understand your medium.
4. Gradients can create subtle transitions that are really pleasing to the eye yet can present potential design disasters if used inappropriately.
5. It is a designer's responsibility to consider all design effecting scenarios
6. Both developers and designers can stand to learn a little from each other

CSS and modern web development

If you were developing for the web 10+ years ago, you most likely became extremely familiar with the <table> tag. Note that I say “familiar with,” not “friends with.” Here’s why.

Tables are sizable containers with rows, columns and cells. A table’s purpose is to display tabular data, things like sport scores, weather data and client lists. In 1998, the majority of websites, including high profile ones, were using table-based layouts. The Internet was littered with tables and very few contained anything resembling tabular data.

When a single HTML file contains more than one hundred nested tables… well, let’s just say it becomes extremely difficult to navigate markup like that. When you have bloated code you have larger file sizes, which in turn result in longer page loads, and when it comes to the Internet, speed is king.

It used to be that a simple request from a client to change the position of a logo and the width of a welcome message was nearly impossible, because changing the size of one table cell directly affected all adjacent cells and tables. I personally broke entire designs trying to fulfill such requests. Those were dark times for developers and websites didn’t change their clothes very often in an effort to avoid being caught with their pants down.

Thankfully, we’ve now moved into the age of CSS(Cascading-Style-Sheets). CSS is the backbone of Internet design in the modern age. With it, design can be done outside the grid so that it looks less like pages from a textbook and more like pages from a high-gloss, full-page magazine spread (appropriate content of course).

However, CSS isn’t exactly the new kid on the block. In fact, style-sheets, in one variety or another, have been around since the 70s and CSS1 has been around since 1996. Many of us were actually using some form of CSS to accomplish pretty spectacular designs (albeit terribly coded ones) in the “table” days. At that time we had no idea that CSS extended beyond background-image, padding, and text-decoration.

Thanks to the efforts of CSS design evangelists like The CSS Zen Garden, many of us have seen the light. CSS is more powerful than we ever imagined. We can now redesign an entire website by updating a single .CSS file.

Now that we have CSS, designers are free to create website designs that are only limited by their imaginations, right? Well… that is what most designers believe but it’s not entirely true.

CSS does have a few limitations, but actually the limitations are minuscule compared to the actual problem, browser compatibility.

There would be no way to see the Internet if it weren’t for web browsers. Browsers interpret all the boring code into something we can understand and interact with. Since the 90s, there has been a handful of them to choose from. But browsers each see the Internet a little differently.

Organizations like the W3C (World Wide Web Consortium) have made great progress in implementing standards for browser companies to follow. The problem is these standards can’t really be enforced, only encouraged. For the last 5 years or so, many web developers have been forced disregard some great CSS features because browsers hadn’t caught up to them or had disregarded the standards altogether.

Today most web browsers are fairly W3C-standards-compliant in respect to rendering CSS, with a few exceptions (cough! Microsoft Internet Explorer). And most web developers are no longer limited by browser compatibility.

That being said, there is still a significant number of computers running these (what I would call) “ancient” browsers, so many web developers are forced to program projects with legacy support in mind. But in the end, that doesn’t mean any of us need to go back to tables. There’s enough functionality in the early versions of CSS1 to accomplish most of today’s website designs. You may just need to be a little creative - we certainly were creative with tables.

My advice to web developers and designers is to learn as much as you can about CSS. A user will never appreciate the developers work if they can't accurately interact with it. Likewise, the same user will never experience the designers vision unless it's properly translated into good markup and CSS. A proper job can never really be done with the wrong tools, and this is most evident when one finally learns to properly use CSS.

A Faster Connection ≠ A Faster Website

I am what you might call a man obsessed. I'm obsessed with speed; especially speed online.

In our modern world of high-speed, broadband, ultra-quick, super-fast Internet connections you might think that speed isn't a concern anymore; we have our content-rich websites and the speed at which to download them.
Interestingly though, the faster the connection gets, the less patience we seem to have waiting for a page to load. For businesses this can have a detrimental effect. Lower conversion rates. People who abandon your site for its perceived slowness doesn't make them customers.

The keys to making the content come to us faster in my opinion are as follows:

• Compression
• Making fewer connections
• Serving content from multiple subdomains
• Caching
• Combining content
• TESTING!

Compression

At it's most basic, compression can be achieved by enabling it on the server. This is pretty straight forward on Apache but much more involved on IIS 6. I'd like to cover how to do this in a future entry.
Just turning this on, can see speed gains in my experience of 200 to 300%, of course that's just a number and mileage may vary but let's say in most cases the load time for a site is cut in half. Minifying content like CSS and JS files will also help, as this process removes elements such as whitespace and line breaks that make it human-readable but a computer doesn't need in order to process it.

Making Fewer Connections

The benefits of making fewer client connections to serve content should be fairly obvious but doing so gets the client the content faster which means more conversion and you can do the math on that.

Serving Content From Multiple Subdomains

Parallelize the download of your content. To do this put images on their own subdomain, put scripts and CSS on its own subdomain. This is my preference as it means my browser can open 3 connections to grab content which means the browser doesn't have to wait. Three connections to the server is better than one queueing up all that stuff people are waiting to look at. If it works for FTP, it can work for your website too.

One thing to keep in mind, scripts block. This means that the rest of your page will not render until the scripts you've just included are completely downloaded and evaluated. For this reason put your scripts at the bottom of your page just before the closing </body> tag.

Caching

How often does your logo actually change? Make sure it gets cached. Cached content is hands down faster than getting it over the wire. If your vistors are always downloading the same elements with each page they visit they have have to wait. Luckily this is easy to do. Set an Expires header on your content. Set it a year in the future. Done. Visitor visits site for the first time, gets logo image, and doesn't download it again for 365 days. Now I know what you might think, what happens if we do change the logo? Simple. If the Last-Modified header of your logo image is newer than the one in the visitor cache it caches the newer image for another 365 days.

Combining Content

Going along with the previous points, combining CSS files or JS files together into one will limit the number of connections we make, require us to cache only one of each file, with compression we can make these combined files very lean.

As an example this is how I combine CSS files in ColdFusion:

<link href="/styles/site.cfm" media="screen" rel="stylesheet" type="text/css" />
(Yes that is a CFM file)

In /styles/site.cfm:

<cfheader name="Content-type" value="text/css">
<cfinclude template="file1.css">
<cfinclude template="file2.css">
<cfinclude template="file3.css">



The server combines all the files together and serves only one file, which the browser sees as CSS. One HTTP connect versus three.
This can easily be achieved in your server-side language of choice. And can be done with any of text content, JS, etc.

Another way to limit the connections and combine files is to use CSS sprites. This is especially useful for graphic content that rarely if ever changes. Things like your logo, UX elements, navigation, etc. One file, many graphics, one connection, one cache item.

Testing

The biggest thing to all of this of course is testing. What may seem fast to you might not be so for someone else, and that someone else may have been a potential conversion.

I use many tools to test the speeds at which my pages load. Some of the ones I can't live without include:

• Firebug
• YSlow for Firebug
• Fiddler
• LiveHTTP Headers

To test the speed of a site at 28.8kbps, 56kbps, ISDN speeds (and yes people still do connect at those speeds) never be without Sloppy. This Java application will allow you connect to your content at these speeds. What is great on a ultra-sleek, blazing connection might not be so hot at dial-up rates.

Take this advice with as much salt as you like. This is what we do and it works for us.

What is Dynamic Internet Programming?

I was in an elevator of all places the other day and began doing what I do often, striking up conversations with a stranger. He was a lawyer and I introduced myself as president of Intoria, a "dynamic Internet programming firm." During the discussion that followed, it became clear to me that this gentleman had no idea what the difference between "dynamic Internet programming" and the more common "static Internet programming" was. If the door to his floor hadn’t opened, perhaps I would have had time to describe to him the power that is available online when programming dynamically. Perhaps he’ll stumble upon this blog and understand the important difference.

Intoria is a dynamic Internet programming firm. At this time, I am not describing the team that works here, nor the pace of our office environment. I am referring to the capability of the complex websites we create which are able to change instantly based on user input. For example, have you ever been to a website which shows an out of date copyright year in the footer? This is a perfect simple example of static Internet programming. However, when programming with a dynamic Internet programming language, the website will sense the time the page loads, and always display the current year so it is never out of date.

Take this to an advanced level, complex, ever changing sites that fully respond to user interaction is the basis of sites that are useful. As an example, when you want to book a flight, an airline site needs to find out where you are and where you want to go, then do numerous calculations and computations based on the dates and locations to submit you your results. This would be impossible to program pages for every iteration, so dynamic (or changing) programming is used.

Intoria is a full service Calgary web firm that has extensive experience in dynamic web design. Our team of experts will gladly work with you to achieve your online goals.