Getting Your Content Online
Introduction
This Web Standards Curriculum article aims to provide a quickfire guide for getting your website online. You’ll find out about how to get yourself a domain name and some hosting. You’ll also find out about the software required to upload websites, along with best practice for structuring a site and ensuring you always have safe copies of your work.
What’s in a name?
A domain name is an important component when creating a website: it’s your text-based link to the world—the thing people type into a browser’s address bar to access your site (such as google.com, or apple.com). The best domain names are memorable and straightforward, and therefore superior to the URL you may be given with some free web space, which typically includes your ISP’s domain and your broadband or dial-up username (such as nameofisp.com/~username).
When choosing a domain, avoid complexity. Imagine yourself reading it out over the phone—if you have to say things like “hyphen” or “the numeral two”, or if your spelling of a word is awkward or non-standard, think of a different name. As millions of domains are already in use, it pays to be armed with at least a half-dozen alternatives. For example, try being more specific with your name: there’s no chance that you’d be able to buy gardening.com, but if you added “in” and your location after “gardening” (such as “gardeninginsomerset.com”), you might.
To find out if a domain is already in use, do a search. The majority of domain resellers have a search form, which enables you to search domains with various suffixes (such as .com, .net, .org, and so on—more on those later), but a decent, impartial and non-commercial resource is at www.internic.net/whois.html.
If you’re on a commercial site doing searches, you might be presented with alternatives should your first choice already be taken. In such scenarios, only settle on alternatives if they’re exactly what you’re looking for. Don’t be tempted by strange word combinations or unusual suffixes. People remember “dot com” or their local equivalent (such as “.co.uk” in the United Kingdom). This is less often the case with awkward combinations like “.uk.com” or newer suffixes such as “.info”. Also, if someone else has a domain with a more popular suffix, you run the risk of losing traffic to them.
Note that even if you’re creating a personal site or blog (such as my own Revert to Saved—see Figure 1), it pays to grab a memorable domain. For example, friends and family will find it easier to find your site if it’s based around your name, and domains also make associated email accounts more useful, enabling you to use name@yourdomain.com, rather than a borderline random collection of characters prior to your ISP’s domain. Also, domains have the advantage of being a constant—should you move ISP and “lose” your free web space, you’ll have to start from scratch. However, with a domain name, the address is always the same, meaning that even a move between entirely different web hosts typically only leads to a couple of days of down-time for your site.
When it comes to buying a domain, you have the option of buying it on its own from one of myriad resellers, or buying it alongside a web-hosting account, all from the same organisation. If you’re a beginner, I strongly recommend buying your domain and hosting at once. It means you only have a single company to deal with for support issues, and the company’s system will likely know what’s going on, enabling you to “attach” a newly acquired domain to a hosting account you’ve purchased via an online administration panel. If you decide against this, you can buy a domain name from one company and “point” it at hosting purchased elsewhere. To do this, you’ll need to update your domain’s nameservers and IP address (things that enable the domain to “know” which site it should be pointed at) in line with the requirements of your web host.
Note that pitfalls can occur during the domain buying process. Some sellers inflate prices to make more profit (which is absurd in the current market), and some at the cheaper end of the spectrum charge when you want to move your domain at a later date. Therefore, prior to buying a domain, always check to see whether you can freely move it. Also, don’t be bullied into buying extra domains unless you really need them—if you have your chosen name and a .com, you won’t need a .biz or a .info equivalent as well, so save your money. Finally, if you’re offered private registration during the buying process, it’s worth consideration. By default, your details (name, address, telephone number) will be available when people investigate ownership of your domain; however, for a few bucks, most domain name resellers enable you to “hide” your details, only showing generic details for the registration organisation.
Figure 1: The domain for my blog, Revert to Saved, was carefully chosen. It’s memorable, a string that’s unbroken by hyphens, and has a .com suffix, which is one of the most common.
The host with the most
Once you have a domain name in mind (or already purchased), you need somewhere to upload your site. Chances are you already have free web space with your broadband or dial-up account, but it’s almost certainly restricted in some way, perhaps in terms of bandwidth (the amount of data users can download over a set time period), storage allocation (the number of megabytes or gigabytes you have for storing content), or by way of other technologies (such as support for various types of scripts or for things like databases). Free hosting tends to offer the bare minimum, meaning you could be scuppered should you later want to expand your site’s scope or feature set.
Luckily, improvements in technology have proved to be a good thing for hosting, and competition has pushed down pricing. Cheap hard drives have resulted in paid-for web hosting typically offering masses of space, even on cheap plans. Also, expectations for included features are changing, and so many paid-for hosts provide PHP and MySQL support as a matter of course. In all cases, investigate the technology you’re going to need for hosting the kind of site you’re building before purchasing; if unsure, talk to your potential host’s support, or ensure that a straightforward and affordable upgrade path exists should your requirements change.
There are also further questions to ask. You need to know about levels of data transfer, and what happens if you exceed this level (your site may be temporarily “closed”, or you could be charged), although this is only a major concern for very high-traffic websites; you might want to investigate whether readymade items are available, such as preinstalled scripts, forums and contact forms; and if your plans amount to more than a solitary website, you need to be aware of any restrictions relating to hosting multiple domains or sites on a single hosting account. Also, if you’re relatively new to setting up sites, it’s wise to choose a host where you can speak to an actual human being when you need to, rather than end up stuck waiting for an email to arrive from a semi-automated help system.
A pretty good global tip for hosting is to shop around. Various sites, such as web-hosting-review.toptenreviews.com (see Figure 2), offer opinions and advice regarding the current champions of hosting, and you can also try contacting hosts directly to ask questions. If they respond promptly and suitably, that’s a good indication that you’ll be in safe hands if problems occur later. In any case, take your time and don’t necessarily go for the cheapest option—shop around, do your homework, and ensure the host you settle on is a good match for your needs. As mentioned earlier, though, we recommend that first-timers buy their hosting and domain from the same company; usually, you can then “attach” your domain to your hosting account via an online administration panel, in a straightforward and non-technical manner.
Figure 2: Various websites offer comparative reviews of hosting services, and it’s a good idea to scour these prior to parting with any cash.
Getting it on(line)
Once you’ve got your domain and hosting sorted, you can start putting content online. Your web host will provide you with some pieces of information that you’ll need to keep safe. You’ll likely get details for accessing your account with the host itself, enabling you to access online administration features. You’ll also get details for accessing your site via FTP, which stands for “File Transfer Protocol”. Although the information provided by web hosts varies, you’ll likely be given a username, a password, a location to upload files to (often your URL, but this varies by host), and perhaps a path to the folder where your web pages should be stored. (Note that although you should be able to access your space very quickly via FTP, it can sometimes take up to three days before the entire internet is able to “see” your domain, so don’t fret if people can’t access your site right away after you’ve uploaded it.)
Myriad FTP applications exist, such as the free (but decent) CoffeeCup Free FTP for Windows, and the excellent Transmit for Mac OS X. Some web-design applications, such as Dreamweaver, also offer built-in clients, although most aren’t as fully featured as a standalone equivalent. FTP applications vary massively, but the majority are roughly comparable in terms of workflow. Typically, you’ll have some means of storing favourite locations to connect to (one of which will be your own site). For each favourite, you’ll need the details your host provided you with, as mentioned earlier.
Once you’ve connected to your web space, you’ll see the empty folder structure of your website, which also varies by host. In some cases, you’ll see nothing at all. In other cases, a few default folders might exist for storing things like scripts and visitor statistics. A good rule of thumb is that you should just leave alone any folders that are there by default. Most FTP clients also provide a local view (as in, that of your hard drive)—see the screen grab of Transmit (Figure 3) for an example. To upload a file to your website, you merely have to drag it from the local to the remote location, or click on the local file and choose a relevant “upload” option.
If you’re working with scripts, you may also have instructions to change the permissions of certain files. This is typically done by getting a file’s info and clicking relevant checkboxes, but also might be referred to via a “chmod” option—“chmod” being the name of a Unix command for amending file and directory modes. Most FTP clients also offer many more features, including the ability to compare and synchronise local and remote folders and to automatically set a local folder when a favourite is accessed. Again, shop around, and bear in mind that most FTP clients are cheap (or free) and have fully working demo versions.
Figure 3: Transmit, available for Mac OS X, is a fairly typical dual-pane FTP client, showing a local view on the left and remote files on the right.
Work in progress
In the previous section, I mentioned how FTP clients often show remote and local files simultaneously. This is a good thing—as any decent web designer will tell you, work solely online at your peril. If you screw up a change when working on a live site, the entire world will see it until a fix is made, and if something happens to the site (hosts do take back-ups, but they aren’t always successful, nor as regular as they should be), you lose everything if you’re only working online.
Instead, you should work on local copies of your files and only upload them when they’re ready. By doing this, you can test changes before they’re uploaded, ensuring that they work and that things like text and images are proofed and readable. You can also take back-ups of a site prior to working on major changes, ensuring that if a total disaster occurs, you have a version to fall back on. Only when you’re totally happy with your changes should you upload them.
On site structure, it’s largely down to the individual how things are organised, but it pays to create a sensible folder structure, enabling you to store things like images, PDFs, MP3s and movies in specific, named folders (see Figure 4), rather than bunging everything in the root folder of the site, which can be messy and make things increasingly hard to organise and sort over time. Some web designers also advocate placing stylesheets, JavaScript documents and even groups of web pages into named folders, although this is only really necessary when you have a fairly large number of them. Over time, if the site expands, it may be wise to add sub-folders within folders, to better organise media.
Figure 4: A fairly typical site structure, awaiting content.
From a development standpoint, ensure your local and remote folders are identical in structure, otherwise updating and keeping your “test” and “live” sites consistent will be borderline impossible. (Note also that some hosts request that certain file types be placed in specific folders. The most common example of this is CGI scripts, which often have to be within a cgi-bin folder to run. Also, some configuration options—such as for databases—are host-specific. As always, ask your host for advice if unsure.)
Summary
Overall, when it comes to everything mentioned in this overview, caution and research are the two most important considerations. Don’t rush headlong into anything and you won’t make a costly mistake. Do your research (on domains, hosts, how best to use your web space, and how to upload and maintain your site), and you’ll have an easier time of it.
Note: This material was originally published as part of the Opera Web Standards Curriculum, available as Supplementary: Getting your content online, written by Craig Grannell. Like the original, it is published under the Creative Commons Attribution, Non Commercial - Share Alike 2.5 license.