Welcome to Web 1.0
A lot has been written over the past few years about the development of Web 2.0, and the rise of user generated content. Facebook, eBay, YouTube, et al. have gained millions of users consuming the content that they repackage and wrap up in with adverts. Surely, anyone who wants to start a web site nowadays has to include the ability for others to generate content for them, and hence attract new users who will generate even more content in a virtuous circle of content creation and consumption. I'm setting my sights a bit lower than this. Perhaps not lower, but in a different direction.
The primary aim of this site is to provide a place for me to showcase the games I've been working on. I understand that it's unlikely that I will generate a large amount of traffic through this site, but it would make me happy if I could get a few people through here every day. There are many different sites out there already that give people the opportunity to play games for free on the web (e.g....), and I don't have the resources to compete directly with these sites. I am just one person, and games take a lot of effort to write. So, I will try to add something a bit different to the mix by documenting the work that I'm doing so that I can share what I'm learning as I learn it. I'll start in this post by discussing my thoughts about creating this site from scratch. If anyone ever gets to read this then I must, to some extent, have succeeded. Look around at the page you're viewing and you can judge the success of my endeavours. Hopefully this page will provide an introduction to some of the technology that is used to create the web, and explain why the site I'm putting together is missing some of the basic functionality that has become common to many other sites.
Content Management
There are lots of different website creation tools out there, and some of them are free. Content managment systems, such as WordPress and Drupal allow users with very little knowledge of web technologies to create professional looking web sites, with complex features. At present, I would count myself among the people with very little knowledge of web technology, so perhaps I am their perfect target. I have looked at a couple of these, however, and decided that they aren't for me. It may be that I could get up and running much faster using them, but that wouldn't be the point. The project that I've embarked upon is one of discovery and learning. I don't just want the end results, I want to find out how things work underneath.
So, as I start to produce some content by actually sitting down and writing this blog, I have some ideas about how I want the web site to look. I want to present things in a minimalist style, with a simple recognisable navigation bar at the top of every page. I would like to link to items of content through an icon based presentation system, a bit like the desktop on a smartphone. Hoverring the mouse over an icon should display some details about it in a text box somewhere. I would like to create a home page that automatically updates to present new content as it is added to the site, along with summary pages for each of the different types of content (currently, I imagine only blog posts and games) which again update automatically as new content is added. I would like the process of adding new content to be as simple as possible. It would be nice to add an RSS feed, support for people to add comments if they like what they've seen, and maybe some sort of site search functionality, but all that is much less important.
Hyper-Text Markup Language
Having done a bit of digging around, I think I know the technology that I will need to explore to get a site like this working. I don't yet know what the site will look like when I manage to get it working on the net. At the moment, I am writing in a text editor, into a file that I have named blog1.html. Html will be the first technology that I use to create the site. Hyper-Text Markup Language is a way to specify to a browser how to display web page content. The Hyper-Text bit of it refers to the ability to specify links to other documents, that can be viewed if the link is clicked. It is the basis of everything that we see on the web today. It will give me the basic foundations of a system to get this blog post out to the world.
Even in my limited experience of html, it is clear to me that it can quickly become very complicated and difficult to write. Each heading and each block of text can be displayed by the browser using particular fonts, sizes, and options. As I'm writing, I don't want to have to worry about specifying these things. So, I plan to make use of Cascading Style Sheets. CSS is a way of specifying the display options for a site in a single file, which is then included into each page on the site. This makes the creation of each page much simpler, as a single line of html can be typed instead of multiple style definitions. It also makes maintenance much simpler. If I decide to change the default size of the typeface used on the site, I only need to change one file rather than editing all the pages on the site. Style sheets are described as 'cascading' because multiple different style sheets may be active within any particular page. When a browser wants to find the appropriate style for a particular block of text, it will first look for any style definitions in the html document, and use those. If the values aren't specified there, it will look in any global style definitions provided by the site. If it still can't find what it's looking for, it will use global values specified by the browser user, and if it still can't find anything, it will use default values.
JavaScript
Html is all well and good for static pages. It is not programming language though, and it cannot provide much in the way of user feedback beyond following links from page to page. To start to flesh out the site I want to create, I will need to start looking into JavaScript. JavaScript is a programming language, and it is understood by all modern browsers. When a page including javascript is downloaded and parsed by the browser, the scrip is executed on the client computer. It allows a web page to provide more interaction with the user. Javascript can change the appearance of a web page as it is being viewed in the browser without needing any further contact with the web server that provided the page. This is how I imagine I will be able to get my icon based display system to provide more details about the item that is linked to by the icon before the user has to click on it.
Javascript should allow me to add some interactivity to the pages that I write, but this is not the end of the story. I would like to add a simple navigation bar to each page that I write, to give an identity to the site, and proved easy navigation links so that the user never gets lost at a page without links back to the main content. This is the sort of thing that you see all over the place on the web, so you might expect that it would be easy to produce. Unfortunately, html works only within the context of a single page. If you want a navigation bar, you need to specify exactly how it will look and how it will relate to other things on the page within the html file for that page. It is possible to include certain types of content directly in html, but not other html pages. In principle, that means that the html commands for a navigation bar need to be copied into each and every file that represents a page on the web site. Just as I wanted to avoid having to copy the style elements into each page, I also want to avoid doing so with the navigation bar. It would complicate the data and production process for each new page, and make site wide changes very time consuming and error prone. Like html, Javascript is also limited to working within the confines of a single page.
Web Servers
This discussion leads us on to the technology of server-side includes (SSI). SSI allow an html document to include the contents of another html document. This is exactly what I want for my page header. The only slight problem is that this inclusion is done on the web server, before the page is delivered to the client. If I want to try this technology out, I will need to install a web server on my computer. I haven't tried this yet, but I think it should be relatively easy. As far as I can tell, the Apache server seems to be the most popular, and it is free. It can sit on my machine, looking at a local directory of content on my hard-drive and then serve it up to a browser as if it was coming from the internet via an address like http://localhost/blog1.html.
SSI is a fairly simple language for adapting web pages as they are downloaded, although it is apparently Turing complete. The added benefit of installing a web server to develop the web site is that it will also allow me to use a more complex server side scripting language like PHP. PHP originally stood for Personal Home Page, but has grown and adapted from this origin, as has the interpretation of of the abbreviation. It has now been renamed PHP Hypertext Parsing, in some sort of circular self referential abbreviation. PHP seems to be complex enough to allow me to move on to develop pages that will automatically update themselves as new content pages are added, by searching for available content at the point that a web page is requested for the server. Links to this content can be added to the page programmatically.
Flash
Some of you out there might be wondering why I'm not using flash for all this. This is meant to be a site dedicated to flash games, after all, so why not create the interactive, data driven interface to the content in flash as well? I did consider this, but decided against it for a couple of reasons. Firstly, as far as I can tell, flash does not have direct access to the file system on server or to a database housed on the server. It would need to query the content via another method, such as PHP, which would mean that I still need to set up a web server and backend script sytem. The second reason is that flash content doesn't interact very well with search engines. Search engines visit web pages and store information about the html content that they find there, and then follow any links on those pages to discover more pages to add to their records. Any content that is delivered to the user through the flash player is missed from this process. I don't expect the pages on this site to rank very highly in google searches, but it would be nice to know that they were out there and I could find them with a few specific search phrases.
So, I think I've managed to find out enough about how web pages work for me to begin putting a site together. Quite how long it will take for me to get something I'm happy with is unclear. As well as putting the technology together, I will also need to work on the visual aspects of the site presentation and try to get together some content to fill it up with. This has been my first attempt to write something down, and already it has taken me several hours of writing to get this far, and I still need to re-read and edit this to try to get it to make some sort of sense. Will this piece ever see the light of day on the site that I've been talking about creating? We'll have to wait and see. I will enjoy the process of trying to make it happen.