To be successful...
Pacific Studios was built specifically to help those building or maintaining websites and the associated photography and video that are so common online now thanks to the proliferation of related online services, broadband internet access, cheap and easy-to-use digital cameras and video cameras, and hosting solutions that are easier now than ever before. This site is provided by David Campbell, Founder and President of MarineBio.org, Inc. where since 1998 he has been learning, building and running one of the most popular and important online sites concerning marine life and its conservation. This site contains what he has learned over the years from the countless people online providing their input, time, knowledge, and help to improve not only marinebio.org but all sites and therefore the Web itself. I thank you all for your tireless assistance and priceless skills that you chose to share with us all.
Building Websites
Building a website is often a painful experience. It can be expensive in terms of both time and money. Many put it off after becoming overwhelmed with the jargon like domains, ftp, SSL, ASP, javascript, flash, jpg, gif, SEO, etc. The truth is that you need a team to create and then run a successful website. What exactly is a "successful" website? A site that helps you achieve your business goals is one answer and probably the most important one. A site that helps visitors achieve their goals is one I like better and if done properly coincides with your business goals.
In this section I will share what I know about building websites from deciding to building one, picking a domain name, deciding on emails, creating the site structure, planning content creation, generating photos and video, testing and optimizing it all, and launching it on the Web as well as ways to generate traffic. Once your site is live, the work then really begins. I'll share what I've learned to help you keep your site fresh and proactive in terms of responding to visitors feedback, statistics, error logs, reviews, etc. Once a site is live it's in the public realm and if you let them, they will help guide you to even further success. Let's get started...
Online Photography/Videography
In this section I'll explore first taking great photographs and video. "Garbage in Garbage out" is a saying I like, which means simply that if you start with bad photos or video there's little you can do to make them great and you might as well not even bother trying. I have wasted untold days trying to "fix" bad photos and video and the results are almost always the same, the delete key. Taking great photos or video or paying the experts for their skills is the way to go and today it is cheaper than ever to find great photos and videos online for reasonable prices.
Knowing ahead of time what you plan to use your photos and videos for helps in numerous ways as well. Using them exclusively for online purposes greatly reduces your requirements for camera gear and computer hardware to convert them to multiple formats. Most of the classic rules for taking photos and video apply for online media and we'll explore them as we learn about what's needed to produce world-class online photography and videography. This way to the studios...
Hardware & Software
Computers, cpus, RAM, video cards, firewire, scanners, monitors, flash media, etc. What's required, what's recommended, and what's new? I'll share where I go, who I ask, and what I use to produce what I need for marinebio.org and the other sites I manage. Hardware can be expensive, a real pain to work with, and even dangerous when it fails. I'll start with the basics that I've learned to help you keep your data safe and your black boxes of hardware happy. It starts with an understanding that there are no ghosts in the machine.... Bring your tea, you'll need it...
Software... hmmmm. The good thing is that software is now better than it's ever been and only getting better, for the most part. I'll share what software I use, how I use it, and most importantly why I chose what I have. We'll explore alternatives and the deep resources online that are simply priceless to everyone using software. Software central, next stop...
Articles & Resources
This site will always be a work in progress, as are all good sites. I'll add articles by myself and others as time goes on to help you (and me) keep abreast of the latest developments and news concerning building successful websites and working with photos and video online.
Testing
Here is a checklist of things to run though before going public with your web-site. Most of them are things which seem to have been overlooked by large numbers of web developers.
The Checklist
Validate the HTML
The first stage of checking a web-site is to make sure that you have valid HTML (or XHTML). This can be done with a validator such as the W3C validator or WDG validator. Your own browser may ignore certain errors, but there is a significant risk that markup errors will result in display problems in some browser or other.
There are sometimes reasons for including invalid HTML. For example some pages on my own site use the non-standard NOINDEX element, for the benefit of my site search engine. But you should only tolerate HTML validation errors if there is a clear need for the non-standard markup, and if you have tested the result in a variety of browsers.
Validate the CSS
CSS can be validated with for example the W3C CSS validator. The considerations here are much the same as HTML validation. It may sometimes be necessary to use something non-standard to get Internet Explorer to work, but such rules can be placed in a separate CSS file and hidden in an Internet Explorer conditional comment, where they won’t bother other browsers or a validator.
Check for broken links
Obviously you don’t want broken links on your site. There are various tools available to help find these, such as the Link Valet (which is convenient for checking a few pages) or Xenulink (convenient for checking a whole site).
Try varying window-sizes
A very important aspect of web design is coping with different window sizes. Window widths may vary from about 200 pixels on a web-enabled telephone to 2000+ pixels on a technical workstation in full-screen mode. While providing a readable site to the very smallest screens is something of a challenge, your site should at least be readable on a wide variety of sizes. As of mid 2006, nearly 20% of all readers are still using screens of 800x600 pixels or smaller, and if the reader wishes to compare the contents of your site with another document, it is entirely possible that he/she may want to use a window-width of around 400 pixels.
Fortunately, at least as far as the text goes, this is not very difficult – just refrain from specifying sizes in pixels or points and you are most of the way. See my flexible design page for further thoughts.
It is obviously easy to test window-sizes smaller than your own screen-size. Testing larger window-sizes might seem impossible, but you can do a rough simulation using the zoom facility of the Opera browser – zoom down to 50% and you get a screen twice the size. It may not be very readable, but any major layout errors should be obvious.
Incidentally don’t worry too much about the very long lines of text that appear at large screen sizes when small fonts are used. If the reader doesn’t use a large font, he can always reduce the window size to something comfortable – that is, after all, half the point of having windowing user interfaces in the first place. But if you wish to, you can also use the CSS2 ‘max-width’ property to limit column width, just as this page does. (Only discerning readers are currently able to benefit from this, as IE does not support it. Rumour has it that it will finally appear in IE 7 – I suppose eight years late is better than never.)
Try varying font sizes
Some people use large screen fonts because they have a large screen with a very fine resolution; other people have to use large screen fonts because of declining eyesight. On the other hand, some people like to use microscopic fonts with their nose pressed against the screen (it takes all sorts...)
So while doing the above activity, adjust the default text-size in your browser, and check that all the text scales appropriately. (You did specify the text size in ems or %, didn’t you? If not, see my font-size page.)
One other aspect to consider is that users may impose a minimum font size to make sure that all text is readable for them. This means that font sizes show a smaller range than you had in mind. If you have a complex page with a wide range of font sizes, it would be worth imposing a minimum size larger than your smallest font (this can be done in e.g. Opera or Firefox) and checking that this does not make parts unreadable.
Download Speed
Access the site via a modem
So you think you have a great site, full of beautiful images. Put your site on the server, then dial in via a modem (a real modem – not an ADSL gateway, which is sometimes erroneously referred to as a modem). Does it look so good half a minute later? Or are you still staring at a pretty-much blank screen?
If the opening page of your site takes more than about 15 seconds to appear, then you are losing visitors fast. (Broadband users generally expect a still faster response.) Don’t overload it. If you have to include large objects on your site – perhaps it revolves around high-resolution reproductions of fine art – put them on later pages and tell (or warn?) your users what is coming.
Web developers generally have broadband access, and they sometimes forget that the majority of the world's internet connections still run via a modem. Yes, more and more people are getting broadband, but the number of people without it is still large, and many people in rural areas, let alone developing countries, simply can’t yet get broadband. By the way, don’t make the mistake of assuming that you don’t have to worry about bandwidth issues if your site is mainly aimed at companies. I have more than once worked at companies which did have a broadband connection, but had it shared between so many users and applications that the net result was scarcely faster than a dial-up modem.
Check image size specifications
While doing the test above, check that at least the text of the page appears quickly. If it doesn’t (or if it dances all over the place while the page is loading) it is probably because you have forgotten to specify HEIGHT andWIDTH attributes on some of your images. Specifying these enables the browser to work out where the text needs to go, and to display it before the images have finished downloading.
Accessibility (for the disabled)
Since I first wrote this page, it has been pointed out to me that actually most of the page is about accessibility: that is, ensuring that a web page is accessible under a wide range of browsing conditions. However accessibility is often used in the narrower sense I use in this section.
Test accessibility
This is mainly important for handicapped users, but also relevant for e.g. people who use a text-only browser, or disable images, because of a slow connection. See the Web Content Accessibility Guidelines.
Automated accessibility checking does need to be taken with a pinch of salt. Many aspects of the guidelines require human judgement to say whether a page is accessible or not – for example whether HTML Heading tags are used correctly. And even when the guidelines are unambiguous, you don’t need to follow them slavishly. For example the absence of a caption on a table is unimportant if the previous paragraph explained what the table is about. Nonetheless it is well worth running a few pages through a checker such as Bobby orAccessibility Valet in order to familiarise yourself with the issues involved. You can then make the necessary improvements.
View in text browser
It is also worth running pages through a text-only browser, or text-browser emulator to see what e.g. a blind person using a text-to-speech converter will encounter. It will help you pick up on badly-chosen or missingALT texts for example. It also shows you the site pretty much as a search engine will see it. Incidentally the Opera browser has a built-in text-browser emulator.
Browser independence
Your site may be viewed in a large variety of situations: different browsers, different operating systems, different features enabled or disabled. It is important that your site stands up well in these different situations. The first point of attention here is validation – described separately above. Then there are the following points.
Try different browsers
Almost all web developers (ahem! – perhaps that should read “quite a lot of web developers”) are aware of the need to check how their site looks in a variety of browsers. How far you go obviously depends on the resources available – not everyone is in a position to check Windows, Mac, Unix and Linux platforms. The minimum test would probably be:
-
Firefox, as that has the best standards compliance and is the second most-used browser;
-
Internet Explorer for Windows – currently the most widely used browser. It is essential to check both versions 6 and 7 as version 7 fixed quite a lot of bugs in 6 but introduced a new set of its own. (Microsoft is however still kicking developers in the teeth by not making it possible to install both versions on the same computer; you will either need two computers or one of the work-arounds available on the net.) Version 5 should preferably also be checked; as of spring 2008 the number of users is not yet negligible. However it is now uncommon enough that you needn’t worry about cosmetic issues; as long as the site is readable that should be sufficient.
-
Opera – growing in popularity due to its speed and pretty good standards compliance.
For some time I also recommended checking Netscape 4 as well, as it often produces radically different results from any other browser, and was very popular for a long time. However the number of users of this bug-ridden browser is now so small (under 0.1% and decreasing) that it can now probably safely be ignored.
Check printed pages
Print some of the pages on a normal printer (i.e. with a paper size of A4 or Letter) and check that they appear sensibly. Due to the somewhat limited formatting options available for printing, you probably can’t achieve an appearance comparable to a document produced by a word-processor, but you should at least be able to read the text easily, and not have lines running off the right-hand side of the page. It is truly extraordinary how many site authors fail to think of this most elementary of operations.
You should also consider using CSS to adjust the appearance of the page when printed. For example you could – probably should – suppress the printing of information which is not relevant to the printed page, such as navigation bars. This can be done using the “@media print” or “@import print” CSS features.
Some sites provide separate “printer friendly” versions of their pages, which the user can select and print. While this may occasionally be necessary as a last resort, it significantly increases the amount of work needed to maintain the site, is inconvenient for the reader and shouldn’t usually be needed.
Switch Javascript off
There are unfortunately quite a number of Internet sites which abuse Javascript by, for example, generating unwanted pop-ups and irritating animations. There are also a number of Javascript-related security holes in browsers, especially Internet Explorer. As a result a lot of readers switch Javascript off – indeed I often do myself. (I have a page giving the reasons in more detail.) Some organisations even block the usage of Javascript completely. Furthermore few, if any, search engines support Javascript.
It is therefore important to check that your site still functions with Javascript disabled. A lot of sites rely – quite unnecessarily – on Javascript for navigation, with the result that the lack of Javascript renders the site unusable.
Clearly if you need it for essential content, that functionality will be lost. But there is no reason why the basic text of the site should be unavailable.
Avoid nearly-meaningless messages like “Javascript needed to view this site”. If you have something worth showing, tell the user what it is, e.g. “enable Javascript to see animation of solar system”.
Switch plug-ins off
The considerations for plug-ins (such as Flash or Java) are very similar to those for Javascript above. Check the site with any plug-ins disabled. The basic text and navigation should still work.
Interest the reader sufficiently, and he might just go to the trouble of down-loading the plug-in. Greet him with a blank screen or a “You need Flash to read this site” message and he will probably go away, never to return.
Switch images off
If scanning a number of sites quickly for information, many readers (including myself) switch images off, for quick loading. Other people cannot view images. So switch images off and check that the site is readable and navigable. This means, in particular, checking that sensible ALT texts have been provided for images. (This check is similar to using a text browser, but not quite the same).
Other checks
Check non-reliance on mailto
In order to give readers a chance to contact them, web authors often include a link of the form “mailto:abc@xyz.org”. However this unfortunately does not work for anything like all browser/e-mail client combinations. And people in e.g. an Internet cafe cannot use this type of link. Indeed the figure is sometimes circulated that as many as 50% of readers cannot use mailto links. While I doubt whether the true figure is quite this high, it is a substantial number. Many readers prefer a form anyway: most of the responses I get to this site come via the contact form rather than the mailto link.
Therefore the best thing is to provide a contact page which has both a mailto link and a contact form; the user can then choose which to use. See my own contact page as an example.
Check for orphan pages
An orphan page is one that contains no links back up to its ancestors – i.e. to pages higher in the hierarchy of the site. Once one arrives at an orphan page, the only way to get to the rest of the site is via the ‘back’ button. Which is fine until people arrive at the page via a search engine, or via a link that someone else gave to them. They cannot then visit the rest of the site. (True, they may be able to get up the hierarchy by lopping off the end of the URL, but this depends on how the site is built, and is in any case not reader-friendly.) So ensure all pages include a link back up the hierarchy.
Orphan pages are particularly easy to overlook in sites with frames. Remember that when one addresses the page directly the other frames are absent.
Check sensible page titles
Check that the page titles (i.e. the contents of the <TITLE> elements) are sensible. Page titles are important, as for example they show up prominently in search-engine results, in bookmarks and also on the tabs of multi-tab browsers such as Opera. Generally speaking, each page of a site should have a unique title. They seem to be somewhat prone to the dreaded cut & paste disease. The “grep” tool is convenient for quickly checking the titles in all your page source files.
A quick web search reveals over a million pages with the illuminating title “New Page 1”, while “Untitled” pages run into several millions.
If you have suggestions, comments or would like to contribute to this website, feel free to contact me.
About | Site Map | Privacy Policy | Contact | © 2009 Pacific Studios
