Archive for June, 2008
« Previous EntriesTaking Your Website Mobile.
Monday, June 30th, 2008You might have tested your website on every computer browser you can find, but nowadays that’s just not enough. Nowadays the web is getting more and more mobile – it’s being used on mobile phones, PDAs, and all sorts of other small devices that can be used on-the-go. You need to allow for these visitors as well, but that’s easier said than done.
So What’s the Problem?
Well, unfortunately, there are dozens of manufacturers of mobile devices, and each one produces hundreds of different models. There has been little standardisation among mobile web browsers: basically, the only real way to check whether your website will work on one or not is to test it. As you can imagine, with all the devices out there, that’s something that you could never really do – especially considering that new devices come out every few months or so.
All you can do, then, is make your site generally suitable for as many mobile browsers as possible, instead of trying to alter it to work perfectly with specific makes and models. When you do this, there are a few basic rules to remember.
Make Things Work Without Images.
Many mobile browsers can’t display images, which means that you’re in trouble if your site uses images to display vital information or to make a form work. You need to test your site with images turned off to make sure everything still works. If you’re using images on a form, you might consider replacing them with Javascript to insert images – as most mobile devices don’t support Javascript, this approach won’t cause any problems for them.
Be Light on Bandwidth.
Most mobile devices are still accessing the web at sub-dialup speeds – that makes your page’s loading time very important to them. Sure, they’re not spending time downloading images, but they still have to download all of your page’s source code before you can display it. You should make sure that your source code is as compact as possible, not repeating itself or using long-winded methods of doing simple things.
This is one of those times when it’s good to know HTML and have written your code yourself, but if you’ve used a WYSIWYG editor then you should at least try running the code through HTML Tidy, to see if you can reduce its size at all that way.
Watch Out for Screen Width.
You’ve got to realise that mobile devices have a much smaller screen width than even the tiniest computer monitor. This makes it very important to make sure that your website (without images) will work on very small screens – the biggest problem here is tables, which never work well. Better compatibility with mobile devices is yet another reason to switch your site over to valid XHTML and CSS, instead of relying on old table hacks for layout.
The Rewards.
If you can take your website mobile successfully, then there’ll be all sorts of rewards. Mobile shopping is still quite new, and there are lots of people trying it out for the first time and starting to build loyalty – you can get a lot of long-term customers if you get into it now. People are also far more likely to pay for small pieces of information or downloads, since they can pay quickly and easily using their phone instead of a credit card.
Of course, even if you’re not selling anything, a mobile website can still be good promotion. Mobile users are especially likely to use your website to try to get your phone number, or directions to where you are – do you really want to let these people down? Anyone who’s taking the time, trouble and expense to look up your site on their phone is likely a loyal (or potentially loyal) customer, and you want to make things easy for them.
Taking HTML Further with Javascript.
Saturday, June 28th, 2008Once you've built your HTML pages, you might need them to do something a little more interactive on the client-side (that is, in the visitor's web browser). How can you do that? Javascript is the answer.
How Does Javascript Work?
To add Javascript to your HTML, you simply insert it between <script> tags (or refer to the .js file that contains it, also using script tags). Overall, Javascript is quite a C-like language, but manages to be relatively simple in spite of it.
The Javascript you write should have functions that are tied to events on the page, meaning that when the visitor does something with your page, the Javascript executes.
Here are some events that you can use to trigger Javascript functions:
onload. Runs the code when the page loads.
onclick. Runs when the mouse is clicked. You can also use ondblclick for a double-click.
onmouseover. Runs when the mouse pointer is over a certain part of the page.
onkeypress. Runs when you press a specific key on the keyboard.
onchange. Runs when the contents of part of a form changes.
onblur. Runs when you press the tab key to switch between part of a form.
onsubmit. Runs when the form's submit button is pressed.
What are these events useful for? All sorts of things. The onmouseover function, for example, can be used to rewrite parts of the page's code when the user hovers over something – useful for providing pop-up help 'tooltips'. Onkeypress lets you give the user keyboard shortcuts to do things on your web page. Onblur and onsubmit can be used very effectively to spot errors in a user's form input, and let the user know how to correct them before they're ever even sent back to the server.
Once you know which event you want to tie some Javascript to, you have to say so in your code. You can do this in one of two ways. The first way is to directly attach it to the HTML element in question, like this:
<form onsubmit="javascript:submitCheck();">
This works well, but has the disadvantage of polluting your HTML with Javascript function names. The second, better, way, is to do it like this in the Javascript itself:
onload = function() { }
This creates a function directly from an event (in this case, the onload event), without ever touching the HTML itself.
Javascript Commands.
Here's a quick reference to the most useful commands in Javascript.
alert. Pops up a dialog box giving the user a message. Useful, but sometimes considered annoying – it might be better to put the message on the page instead.
confirm. Gives the user an alert box, but with buttons for Yes and No. Useful for asking 'are you sure?'
document.write. Writes things into the current HTML document. Often-used, but not the best way of doing things.
getElementByID. Allows you to get an HTML element (that is, a tag) using its ID and manipulate it. Very useful for changing the text contained within tags, or their background colours, but can be used to do just about anything.
Math.random. Produces a random numb
navigator.userAg. Returns the name of the web browser. Useful to check if a certain browser is being used, although it's often better to check for functions instead of browsers and decide which code to run that way.
parseInt. Looks through some text and gives you only the numbers from it.
window.location. Allows you to change the current URL that the web browser is at, as if the user had clicked a link.
var. Defines variables.
For more on Javascript, take a look at www.javascriptkit.com.
Javascript's Problems.
The biggest problem Javascript has is that it just doesn't work on all browsers: if you thought HTML support was erratic between them, wait until you start using Javascript. This will often put you in the position of having to check whether a function is available on the browser the code is running in (using an if statement), and then running some alternative code as a workaround if it doesn't. In most cases, this isn't as big a problem as it might seem, but it still requires you to have some knowledge of each browser's limits, and do more testing than you would otherwise need to do.
Javascript is also, unfortunately, a pain to test and debug, as most browsers don't give you any sort of reason why your code didn't run – if it's wrong, they just ignore it.
Taking HTML Further with Javascript.
Saturday, June 28th, 2008Once you've built your HTML pages, you might need them to do something a little more interactive on the client-side (that is, in the visitor's web browser). How can you do that? Javascript is the answer.
How Does Javascript Work?
To add Javascript to your HTML, you simply insert it between <script> tags (or refer to the .js file that contains it, also using script tags). Overall, Javascript is quite a C-like language, but manages to be relatively simple in spite of it.
The Javascript you write should have functions that are tied to events on the page, meaning that when the visitor does something with your page, the Javascript executes.
Here are some events that you can use to trigger Javascript functions:
onload. Runs the code when the page loads.
onclick. Runs when the mouse is clicked. You can also use ondblclick for a double-click.
onmouseover. Runs when the mouse pointer is over a certain part of the page.
onkeypress. Runs when you press a specific key on the keyboard.
onchange. Runs when the contents of part of a form changes.
onblur. Runs when you press the tab key to switch between part of a form.
onsubmit. Runs when the form's submit button is pressed.
What are these events useful for? All sorts of things. The onmouseover function, for example, can be used to rewrite parts of the page's code when the user hovers over something – useful for providing pop-up help 'tooltips'. Onkeypress lets you give the user keyboard shortcuts to do things on your web page. Onblur and onsubmit can be used very effectively to spot errors in a user's form input, and let the user know how to correct them before they're ever even sent back to the server.
Once you know which event you want to tie some Javascript to, you have to say so in your code. You can do this in one of two ways. The first way is to directly attach it to the HTML element in question, like this:
<form onsubmit="javascript:submitCheck();">
This works well, but has the disadvantage of polluting your HTML with Javascript function names. The second, better, way, is to do it like this in the Javascript itself:
onload = function() { }
This creates a function directly from an event (in this case, the onload event), without ever touching the HTML itself.
Javascript Commands.
Here's a quick reference to the most useful commands in Javascript.
alert. Pops up a dialog box giving the user a message. Useful, but sometimes considered annoying – it might be better to put the message on the page instead.
confirm. Gives the user an alert box, but with buttons for Yes and No. Useful for asking 'are you sure?'
document.write. Writes things into the current HTML document. Often-used, but not the best way of doing things.
getElementByID. Allows you to get an HTML element (that is, a tag) using its ID and manipulate it. Very useful for changing the text contained within tags, or their background colours, but can be used to do just about anything.
Math.random. Produces a random numb
navigator.userAg. Returns the name of the web browser. Useful to check if a certain browser is being used, although it's often better to check for functions instead of browsers and decide which code to run that way.
parseInt. Looks through some text and gives you only the numbers from it.
window.location. Allows you to change the current URL that the web browser is at, as if the user had clicked a link.
var. Defines variables.
For more on Javascript, take a look at www.javascriptkit.com.
Javascript's Problems.
The biggest problem Javascript has is that it just doesn't work on all browsers: if you thought HTML support was erratic between them, wait until you start using Javascript. This will often put you in the position of having to check whether a function is available on the browser the code is running in (using an if statement), and then running some alternative code as a workaround if it doesn't. In most cases, this isn't as big a problem as it might seem, but it still requires you to have some knowledge of each browser's limits, and do more testing than you would otherwise need to do.
Javascript is also, unfortunately, a pain to test and debug, as most browsers don't give you any sort of reason why your code didn't run – if it's wrong, they just ignore it.
Taking HTML Further.
Thursday, June 26th, 2008HTML might seem like a simple language for web documents, and to an extent, it is – that's what it was intended to be. If you know what you're doing, though, you can do a lot more with HTML than you might think. This article should give you a few ideas on how to take HMTL further.
Inserting Multimedia Content.
Plain text and graphics are all well and good, but sooner or later you're going to want to insert some multimedia content, such as a Flash movie, or an audio or video file. Unfortunately, browsers don't handle these things themselves – they use plugins, and you have to know the code to activate these plugins. While this should be simple, it isn’t, for various historical reasons.
To begin with, there are two ways entirely different ways of calling a plugin. Newer browsers use the object tag, like this:
<object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000"
codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab"
width="200" height="200">
<param name="movie" value="myFlashMovie.swf">
</object>
That one's for Flash. To insert things like Quicktime or Windows Media players, you just need to find out their classid and codebase URL, as well as which parameters (param tags) they require. Most browsers now support the object tag, but some still use the embed tag instead:
<embed src="/support/flash/ts/documents/myFlashMovie.swf"
width="200" height="200"
type="application/x-shockwave-flash"
pluginspage="http://www.macromedia.com/go/getflashplayer">
</embed>
For most cases, you should include both – it's best to place the embed tag inside the object tag, as this will cause browsers that understand object to ignore your embed. As an extra fallback, you might want to insert a ‘plugin not found’ message, with a link to allow users to download the plugin, but in most cases browsers should now do this for you automatically.
For Internet Explorer only, you can extend object tags to call plugins that are on your server instead of on your computer – this is known as ‘ActiveX’. Its most common use is to let users install web-based programs such as instant messengers without having to download and run a standalone install program.
However, you have to realise that many users will see ActiveX as dodgy, because it is an often-used way of installing undesirable software, and people who aren’t using Internet Explorer just won’t see anything at all. If you’re designing a site for a limited set of users, however (such as an intranet), ActiveX can be a very powerful capability.
Tables.
Even though tables are rarely used for layout any more, they're still used for what they were originally intended for – actual tables of information! You'll probably need one at some point, but they're still as complicated as ever, so it's good to take a while to learn about how they work.
Basically, to create a table, you have to create the rows and columns individually: each table tag contains row (tr) tags, and each tr tag contains column (td) tags. A typical table looks like this:
<table>
<tr> <td> month </td> <td> sales </td> </tr>
<tr> <td> January </td> <td> 200 </td> </tr>
<tr> <td> February </td> <td> 300 </td> </tr>
</table>
This can be a difficult way to work, especially if your data is organised in columns, not rows. You just need to remember that the data you put in the tds will line up depending on their order in the tr: so, for example, 'sales', '200' and '300' will line up in a column, because they are all in the second td tag of each tr. You might find it easier to use tabs instead of spaces to separate the tds, so the table appears lined up in the HTML the same way it will on the page.
Once you see how that works, you pretty much understand tables – wasn't so hard, was it? The only thing left to realise is that you can make one td fill more than one column using the 'colspan' tag. In the example table, for example, you could add text that fills two columns by adding this row:
<tr> <td colspan="2">text</td> </tr>
Experiment a little, and you should be alright. Good luck.
Some Places to Go For More Information.
Tuesday, June 24th, 2008If you feel like you know quite a bit about web design now, but you’d really like to explore the details a bit more, then this is the article for you. As web designers are, by their nature, very likely to be web users and website owners, there’s a wealth of information and discussion forums on the web, all free to read or participate in. I’m going to give you a few websites that are my first port of call when I have a problem or I’m curious about something, in the hope that they’ll be useful to you too.
W3Schools (www.w3schools.com). A great resource, with free tutorials on everything from HTML to CSS to ASP. It offers a ‘try it yourself’ editor that lets you edit example code and see the results straightaway, as well as comprehensive language references. I go to W3Schools first when I forget the name of an obscure CSS property or wonder if there’s an HTML tag suitable for a certain purpose – they’re all there.
A List Apart (www.alistapart.com). A web magazine for web designers, it’s very good for ‘how to’ articles covering more complicated subjects, especially when it comes to CSS. The writers at A List Apart are very good at working around CSS’ shortcomings and offering practical workarounds and solutions that you can take and use on your own website.
Digital Web Magazine (www.digital-web.com). Weekly pieces on issues relevant to web designers, with a focus on web design and accessibility. It tends to be especially good for reviews of the latest web design books, and analysis of current trends.
The Web Style Guide (www.webstyleguide.com). If you’re a writer, you need to read The Elements of Style, and if you’re a web designer you need to read the Web Style Guide. It is, essentially, an online book, giving best practices for many different aspects of web design. If you’re looking for general strategies, it’s a very good read.
Webmaster World (www.webmasterworld.com). An excellent place to watch for the latest news relevant to webmasters – if something is going on with a search engine, or there’s a new advertising service out, then Webmaster World will have the news, as well as lots of comment and analysis from people who run big, successful websites. Well worth checking daily.
About Web Design (webdesign.about.com). A resource that mostly sticks to the basics, but covers all of them, and covers them well. If you’re trying to do something that seems like it should be quite simple and you’d like a step-by-step guide, About Web Design is a good place to go.
Web Design Bits (www.webdesignbits.com). Web design tutorials with a focus on those big, difficult to use programs, like Flash and Photoshop. Especially good if you’re trying to achieve advanced effects in Photoshop without having to learn it inside out. The tutorials linked to are off-site, making it a good way to find other useful web design websites.
Web Design Forums (www.webdesignforums.net). A pretty comprehensive set of forums about web design, and a very good place to go if you’re having a problem that you haven’t been able to solve for yourself. As long as you take the time to find the right forum to post your question in, you should find the people there helpful and knowledgeable.
The Site Wizard (www.thesitewizard.com). This site has a sprawling, categorised set of web design articles – if you want an article about something, you can probably find it here. It tends to be especially good if you’re looking for a guide for how to do something with a specific program.
SitePoint (www.sitepoint.com). Although it can feel advertising-heavy, SitePoint is a good resource for articles about web design. The articles tend to be slanted towards online business and other ways of making money online, although there are plenty of design tricks there that would be useful to anyway. They also have a very active and useful set of forums.
The W3C (www.w3c.org). Finally, it’s worth giving a mention to the web’s official standards body, the W3C. They have the authoritative copies of the specifications for open web languages like HTML and CSS. You can also take a look at the working groups, who are working on the future of the web right now.
Some Places to Go For More Information.
Tuesday, June 24th, 2008If you feel like you know quite a bit about web design now, but you’d really like to explore the details a bit more, then this is the article for you. As web designers are, by their nature, very likely to be web users and website owners, there’s a wealth of information and discussion forums on the web, all free to read or participate in. I’m going to give you a few websites that are my first port of call when I have a problem or I’m curious about something, in the hope that they’ll be useful to you too.
W3Schools (www.w3schools.com). A great resource, with free tutorials on everything from HTML to CSS to ASP. It offers a ‘try it yourself’ editor that lets you edit example code and see the results straightaway, as well as comprehensive language references. I go to W3Schools first when I forget the name of an obscure CSS property or wonder if there’s an HTML tag suitable for a certain purpose – they’re all there.
A List Apart (www.alistapart.com). A web magazine for web designers, it’s very good for ‘how to’ articles covering more complicated subjects, especially when it comes to CSS. The writers at A List Apart are very good at working around CSS’ shortcomings and offering practical workarounds and solutions that you can take and use on your own website.
Digital Web Magazine (www.digital-web.com). Weekly pieces on issues relevant to web designers, with a focus on web design and accessibility. It tends to be especially good for reviews of the latest web design books, and analysis of current trends.
The Web Style Guide (www.webstyleguide.com). If you’re a writer, you need to read The Elements of Style, and if you’re a web designer you need to read the Web Style Guide. It is, essentially, an online book, giving best practices for many different aspects of web design. If you’re looking for general strategies, it’s a very good read.
Webmaster World (www.webmasterworld.com). An excellent place to watch for the latest news relevant to webmasters – if something is going on with a search engine, or there’s a new advertising service out, then Webmaster World will have the news, as well as lots of comment and analysis from people who run big, successful websites. Well worth checking daily.
About Web Design (webdesign.about.com). A resource that mostly sticks to the basics, but covers all of them, and covers them well. If you’re trying to do something that seems like it should be quite simple and you’d like a step-by-step guide, About Web Design is a good place to go.
Web Design Bits (www.webdesignbits.com). Web design tutorials with a focus on those big, difficult to use programs, like Flash and Photoshop. Especially good if you’re trying to achieve advanced effects in Photoshop without having to learn it inside out. The tutorials linked to are off-site, making it a good way to find other useful web design websites.
Web Design Forums (www.webdesignforums.net). A pretty comprehensive set of forums about web design, and a very good place to go if you’re having a problem that you haven’t been able to solve for yourself. As long as you take the time to find the right forum to post your question in, you should find the people there helpful and knowledgeable.
The Site Wizard (www.thesitewizard.com). This site has a sprawling, categorised set of web design articles – if you want an article about something, you can probably find it here. It tends to be especially good if you’re looking for a guide for how to do something with a specific program.
SitePoint (www.sitepoint.com). Although it can feel advertising-heavy, SitePoint is a good resource for articles about web design. The articles tend to be slanted towards online business and other ways of making money online, although there are plenty of design tricks there that would be useful to anyway. They also have a very active and useful set of forums.
The W3C (www.w3c.org). Finally, it’s worth giving a mention to the web’s official standards body, the W3C. They have the authoritative copies of the specifications for open web languages like HTML and CSS. You can also take a look at the working groups, who are working on the future of the web right now.
Setting up a Test Server on Your Own Computer.
Sunday, June 22nd, 2008When you're developing a website, you need to see it in action on a real server, to see how it will work. While you could upload your pages to your web host every time you make a change, this quickly gets time-consuming and tiresome. Wouldn't it be great if you could have a little test server of your own? Well, the server is nothing but a piece of software – so you can! Please note that, for the purposes of this article, I will assume you're using Windows as your operating system.
Installing an IIS Test Server.
While using IIS isn't recommended, a test server is very easy to install. All you need to do is open 'Add or Remove Programs' in Windows' control panel. All you need to do is click Internet Information Services (IIS), click OK, and you're done.
Of course, there are downsides to this. Many versions of Windows don't come with IIS, and there's no way to install it on them – Windows XP Professional, for example, comes with IIS, but Windows XP Home does not. You might also want to consider that installing IIS on your computer will often make it less secure.
Installing an Apache Test Server.
Compared to installing IIS, installing Apache is hard – Linux distributions all have relatively easy ways of doing it, but Windows wasn't designed for it. To get Apache installed, then, you're going to need to have a little fight with the system.
Note: If you want to skip all the following steps, you might consider using an 'easy installer' version of Apache, such as XAMPP (for Windows), which you can get at www.apachefriends.org/en/xampp-windows.html. The downside to this approach is that you will be relying on them to provide new releases, instead of being able to update things yourself.
First of all, download Apache from http://httpd.apache.org/download.cgi. Make sure you download the Windows Installer (MSI) version. You'll find it easiest to make the server run as a service, as this will make it run automatically – Apache will appear in your system tray (in the bottom-right corner of your screen).
Now, you need to find your Apache configuration file. In the folder where you installed Apache, look for another folder named 'conf', and then a file named 'httpd.conf'. Open this file and look for a setting called DocumentRoot. You should change this to point to a folder on your hard drive, such as 'c:/html'.
Now, you've got Apache, but that's not usually much good on its own. The chances are that you'll want to install PHP and MySQL as well, so here's how:
Download PHP from http://www.php.net/downloads.php. Again, go for the installer. Once you've installed PHP, find its folder, and rename the php.ini-dist file there to php.ini. Find the 'doc_root' setting there, and set it to the same thing you set Apache's to.
Back in Apache's httpd.conf, you should add these lines:
LoadModule php5_module "c:/php/php5apache2.dll"
AddType application/x-httpd-php .php
PHPIniDir "c:/php"
If you didn't install PHP in c:\php, change the lines above to reflect where you put it.
Now, installing MySQL isn't as difficult, because it runs independently of your Apache configuration. Download MySQL from dev.mysql.com/downloads. Again, get the Windows installer version. This installer has a lot of settings, but you'll be fine if you just click Next through them to accept all the defaults.
The only remaining step is to enable MySQL support in PHP. Copy libmysql.dll file from c:\php to your Windows\System32 folder, and then open the php.ini file you created before. Remove the semicolon from the start of the line that says ';extension=php_mysql.dll', and save the file.
Shut down Apache and restart it, and you're done!
Visiting Your Server.
When they've installed a server on their computer, many people wonder how they can access the server they just installed as if they were visiting it over the web. The answer is simple: just open your web browser, and go to this URL: http://localhost (you can also use http://127.0.0.1). This special address means 'the server on this computer'.
You'll know if you installed Apache successfully because you'll see a page congratulating you. When you change your web pages, just use your browser's Refresh button to see the effect.
Setting Up a Mailing List.
Friday, June 20th, 2008If you want people to come to your website more than once then you need to remind them, from time to time, that you exist and give them the latest news about what's changed and what's been updated. One of the best ways to do this is to collect email addresses and use them to create a mailing list. But how do you collect these email addresses and how do you send out emails to so many people all at once?
Collecting the Email Addresses.
Collecting email addresses is easier than you might think. People on the web are used to typing their email addresses in a lot, and usually have an email address to use for this purpose. In most cases, if you ask for an email address as a condition of accessing something interesting sounding people won't really mind giving it to you.
One way of doing this is to simply include a box on each page – unobtrusive and not really calling attention to itself – that gives your visitors the option to sign up to your newsletter. Somewhat counter-intuitively, it is often better to make mailing list sign-up entirely voluntary, as this means you will get a smaller list but it will only have the most enthusiastic people on it.
Basically, it's a trade-off between forcing as many people as possible to sign up or just marketing to the most eager people. Your strategy should usually be decided by how many people you plan to send out emails to and what kind of response rate you seem to be getting.
What to Write in Your Mailing List Emails.
If you want people to read the emails you send to them then they can't just be the latest dull news about your technical website features that no-one even cares about. You need to provide information and updates that are useful and relevant to the person who's going to be opening that email.
If you just write in corporate speak and don't say anything that's going to be useful to real people then your email is going to be going straight into their junk mail. You should take some time over your emails. Make them something that their recipients are going to want to keep and refer to more than once – often-updated, time-sensitive information is best, if you have access to it.
Apart from that, make sure to include links to the latest things on your website, as well as a few older things that are still popular. If you sell anything, you should work in a link, but don't be too obvious about it – a good way of doing things is to include a tip or two with potential uses for a certain product (making them look like they are intended for people who already own the product), sparking the reader's curiosity enough to click through and consider buying it.
The Technical Side.
Once you've got a mailing list and you've written the first email you want to send to it, the next step is to set up the technical side of things. Just how do you think those emails are going to get sent out? Surprisingly enough, you can just use a normal email program like Outlook, if you paste all the email addresses into it. If you do this, though, you need to make sure that you use the Bcc (blind carbon copy) field for the addresses, to avoid sending out a copy of the mailing list to everyone on it.
Alternatively, there are specialist programs you can get that are devoted to bulk mail. Because spam is such a big industry, companies producing such programs tend to be shady – stay away from anything that advertises itself on the basis of how many emails it can send in a minute – but if you look around, you should be able to find something that meets your needs.
There are even web-based solutions that avoid you having to install any programs or send any email from your computer, avoiding the risk that you might get blacklisted somehow for sending out too many emails in too short a time. If you can find a reasonably-priced one, then they're often the ideal solution, allowing you to manage your lists directly and send out emails easily. Make sure to do a few trial runs with smaller numbers of people before you commit yourself to anything, though.
RSS: Really Simple Syndication.
Wednesday, June 18th, 2008More websites are starting to offer RSS feeds, and more users are making use of RSS readers instead of visiting every website they want to read individually. But what is RSS, why is it getting popular, and – most importantly –what can it do for you? Read on.
What is RSS?
RSS stands for 'really simple syndication', and it does exactly what it says on the tin. Invented by Dave Winer, one of the first webloggers, the format aims to provide a standardised way to obtain a website's content, instead of forcing people to try to pick it out of masses of HTML. It is a simple XML (strictly, RDF) language designed to make it easy to describe content.
Information RSS gives you about content includes its title, the dates when it was created and last updated, and its URL. There is also a space for content, which can either be used to provide a summary of the content at the URL or just to provide the content itself.
Which Version?
There is a bit of a controversy about the versions of RSS, for the simple reason that one is wildly different to the others. While RSS 0.9 and 2.0 are broadly similar, RSS 1.0 is widely considered to be a disaster – little software understands or uses it, as it's just too complicated. For most purposes, then, you should stick to RSS 0.9 if what you're doing is relatively simple, and offer RSS 2.0 if you want to give more detail to some of your users.
How is RSS Produced?
While you could write a script of your own to turn your content into RSS (it wouldn't be that difficult if you store your articles in a database), almost all CMSes and blog software packages now do it for you automatically – if you're looking for it, keep an eye out for a small orange button that says 'XML' or 'RSS' on it. All you have to do is give some prominence to the RSS feed, with instructions to your visitors on what it's for and how to use it.
With most software, then, the RSS should be produced either when you update your content or, alternatively, every time someone asks for the RSS. It's important to understand that RSS isn't a 'push' mechanism: updating it doesn't send changes to anyone until their software asks for them to be sent. This often means a window of five to ten minutes between something going in the RSS feed and people seeing it.
How Do RSS Readers Work?
RSS readers work by allowing a user to 'subscribe' to a feed, either by entering the URL of an RSS feed manually or by clicking on a link that starts with feed://. The reader then works something like an email program, retrieving new entries as they are added to the RSS and alerting the user – indeed, they are similar enough that many email programs now include a built-in RSS reader.
When the user opens the new RSS entry, they will see what you put in the content area, usually with a link to open that page of your website in their web browser. You have to realise, though, that they won't see any of your ads or graphics in the RSS feed, so it's best to give them some kind of incentive to click through.
What Else is RSS Used For?
RSS readers might be the most common use of RSS, but the format was designed to be used for almost anything. There's nothing to stop you, for example, from taking an RSS feed from another website and publishing it on yours – you can even be an 'aggregator', mixing relevant content from the RSS feeds of lots of different websites to create a new, more useful website.
That's where the word 'syndication' in RSS' name comes from: it lets you virtually syndicate other people's content on your site, and it lets people syndicate your content on theirs. It benefits everyone, since the one doing the aggregating gets more content for their website, while the one being linked to gets more links to theirs. If you want to do well on the web, you should make sure you've got an RSS fede
RSS: Really Simple Syndication.
Wednesday, June 18th, 2008More websites are starting to offer RSS feeds, and more users are making use of RSS readers instead of visiting every website they want to read individually. But what is RSS, why is it getting popular, and – most importantly –what can it do for you? Read on.
What is RSS?
RSS stands for 'really simple syndication', and it does exactly what it says on the tin. Invented by Dave Winer, one of the first webloggers, the format aims to provide a standardised way to obtain a website's content, instead of forcing people to try to pick it out of masses of HTML. It is a simple XML (strictly, RDF) language designed to make it easy to describe content.
Information RSS gives you about content includes its title, the dates when it was created and last updated, and its URL. There is also a space for content, which can either be used to provide a summary of the content at the URL or just to provide the content itself.
Which Version?
There is a bit of a controversy about the versions of RSS, for the simple reason that one is wildly different to the others. While RSS 0.9 and 2.0 are broadly similar, RSS 1.0 is widely considered to be a disaster – little software understands or uses it, as it's just too complicated. For most purposes, then, you should stick to RSS 0.9 if what you're doing is relatively simple, and offer RSS 2.0 if you want to give more detail to some of your users.
How is RSS Produced?
While you could write a script of your own to turn your content into RSS (it wouldn't be that difficult if you store your articles in a database), almost all CMSes and blog software packages now do it for you automatically – if you're looking for it, keep an eye out for a small orange button that says 'XML' or 'RSS' on it. All you have to do is give some prominence to the RSS feed, with instructions to your visitors on what it's for and how to use it.
With most software, then, the RSS should be produced either when you update your content or, alternatively, every time someone asks for the RSS. It's important to understand that RSS isn't a 'push' mechanism: updating it doesn't send changes to anyone until their software asks for them to be sent. This often means a window of five to ten minutes between something going in the RSS feed and people seeing it.
How Do RSS Readers Work?
RSS readers work by allowing a user to 'subscribe' to a feed, either by entering the URL of an RSS feed manually or by clicking on a link that starts with feed://. The reader then works something like an email program, retrieving new entries as they are added to the RSS and alerting the user – indeed, they are similar enough that many email programs now include a built-in RSS reader.
When the user opens the new RSS entry, they will see what you put in the content area, usually with a link to open that page of your website in their web browser. You have to realise, though, that they won't see any of your ads or graphics in the RSS feed, so it's best to give them some kind of incentive to click through.
What Else is RSS Used For?
RSS readers might be the most common use of RSS, but the format was designed to be used for almost anything. There's nothing to stop you, for example, from taking an RSS feed from another website and publishing it on yours – you can even be an 'aggregator', mixing relevant content from the RSS feeds of lots of different websites to create a new, more useful website.
That's where the word 'syndication' in RSS' name comes from: it lets you virtually syndicate other people's content on your site, and it lets people syndicate your content on theirs. It benefits everyone, since the one doing the aggregating gets more content for their website, while the one being linked to gets more links to theirs. If you want to do well on the web, you should make sure you've got an RSS fede