Monday, May 29, 2006

Create your own development environment - just add water

In the real world you will need a place to try out new web pages before you make them 'live' on the customer facing web site.

Today we're going to build a development environment that allows us to try out dynamic PHP pages on our local machines, with a database thrown in for good measure.

The ingredients we'll need are:

  1. a web server (we'll use Apache)
  2. the PHP interpreter
  3. the database engine (MySQL)
  4. some database management software (phpMyAdmin)
Getting all these things installed and playing nicely together can be a bit of a task. Fortunately there are folks out there who have done it already. One of those, dWebPro, will also run from a stand alone CD which you can give to your customers, relatives and friends.

To save on download times, I've put copies up on the local server - have a look in the dWebPro directory (or go here if you're inside the firewall) and you'll find the following files:
dwebpro_6.5.0.exe       7.9M - the web server
mysql40_package.exe 5.4M - the database software
php4_package.exe 7.5M - the PHP interpreter
phpmyadmin_package.exe 2.9M - database admin software
Download and install each of these in turn on a PC running Microsoft windows and you'll have your very own development environment.

If you installed with all the default options you can run the web server by clicking on the dWebPro icon on your desktop. After the spash screen you should see the phpMyAdmin screen displayed in the web browser. Note the URL. It doesn't point to a local file but calls - you're looking at a page that's being served by a real live web server running on your PC with a local ip address (, using port 8080).

Using it in anger
Now to try it out for yourself. Copy the form and php pages we created last week into the web server home directory. This should be: C:\DWebPro\deploy\www if you used the default installation.

Now open up the form page by entering it's server address in your browser's address bar. Something like:

Submit the form, read the results and take a break.

thanks to David Reeves for "High Purity"

Sunday, May 28, 2006

CSS and multiple media

You might remember, way back when, that I mentioned that your web pages' CSS links can have a MEDIA attribute, which specifies the medium or media to which the style sheet should be applied.

This means you can have one lot of CSS for the screen, and another for - oh, lets say, the printer

it turns out there are ten defined media types:

  • all
  • aural
  • braille
  • embossed
  • handheld
  • print
  • projection
  • screen
  • tty
  • tv

Print is the one you'll see most commonly used. You can find out why, and some of the common tricks used in a print media type CSS file, by reading the article: css vs. media

Try it yourself. Add a print css media attribute to your project 1 hompage which strips out the navigation elements, removes the underlines from links and makes them black, sets the background colour to white, sets the text font to something with serifs and (for bonus marks) prints the URL of clickable links next to the original links on the page - then print it out to make sure it works.

The other up-and coming CSS media star is of course: mobile. The Opera browser folks have a good article on producing mobile content called Making Small Devices Look Great

How do you test the other media attributes?

So, we've seen how to test the print media attribute using your printer. How about the others? Well, you could try looking at mobile types on your G3 mobile phone (or if you're poor you can use an online emulator), and I guess you could always try producing braille types on a handy nearby braille embosser

Of course, if you're using Macromedia Dreamweaver 8, you can use the the "View > Toolbars > Style Rendering" menu option to test various media types in the IDE, including what a page looks like if CSS is ignored altogether.

thanks to adactio for the image: "CSS Mastery"

Tuesday, May 23, 2006

Some XML multi-choice practice

I forgot to mention yesterday - I started to add an XML section to the updated toolbox. You can see it on the Bathurst TAFE server (or here if you're inside the firewall).

There's not much stellar content, but I did put together a short quiz with some typical XML questions, the type of thing you'll be doing in the test next week. Just click on the link marked: Test your knowledge of Complex Mark Up Language Documents

On the usability front, I've moved the activities list to the top of the page and shrunk the banner section to a minimal 20 pixels. I've also given the pop-up windows back all the functionality of a full fledged browser (navigation, menus and most importantly: the ability to be resized). What are your impressions? An improvement? Too much form lost for too little function? Or didn't it make any difference? Once more, feel free to post your comments.

Thanks to john© for "And A Quiz To Round Off The Holiday"

Monday, May 22, 2006

Forms II - they're back, and they're not happy...

When we created our first form we used a php script to list all of the global variables - useful for testing the form, but not much good if we want to actually use the information for something. This week we're going to look at how to get individual form elements into variables so we can bend them to our will.

Setting up

To start off make sure you've given the text area, checkbox and menu form elements meaningful name attributes:

  1. name = "shipname" for the first text box
  2. name = "tripdate" for the second
  3. name = "exploration" for the first checkbox
  4. name = "contact" for the second
  5. name = "species" for the multiselect dropdown menu

To process the form we'll need to create a new php page to process our form: testform.php

This will be a common, or garden variety html page, but buried in the <body> section we need to add a block of php code:


// set a variable from the shipname field on the form...
$shipname = $_POST["shipname"];

print("Thank you $shipname.");

This code looks for an input control on the form called: shipname and assigns it to a php variable: $shipname, it then writes this variable and a quick thank you on the screen.

Update the form so that it's action="testform.php", and upload both files. Don't forget to set the testform.php file permissions to 'execute' so that the web server can run it.

Debug if necessary and once you have it working, try adding code to display the tripdate and exploration elements.

Being Selective

Did you notice how the exploration control returned a value (perhaps something like 'yes')? What we want to do is try some selection on this value before we write the expedition objectives on the screen. Something like:

print("<strong>Mission Goals:</strong> <br />");

$exploration = $_POST["exploration"];

if ($exploration == "yes") {
print("Exploration<br />");

Try adding this code to your own page. You might need to change the comparison string to match the value attribute of your form's checkbox. Once you get this working, add code for showing 'Contact' if the contact check box was selected.

An optional extra:

The final part of the form is a bit trickier. The crew species list can have more than one value selected. This will be returned as an array of values to the php form checking page, and so we need to do a bit of fancy php footwork to access it.

Firstly, we need to give the option control a php array-friendly name. If its currently called: name="species" you will need to add the array delimiters to its name, making it: name="species[]" - you should now have html on your form page which looks something like:

<select name="species[]" size="4" multiple>

In your php file you need to run a for loop through this array, printing each value on the screen:

print("<p><strong>Mission member's species:</strong><br />");
foreach($_POST['species'] as $species) {

print("$species <br/>");

This takes the species array from the post array and itereates through it, assigning each selected species value to a $species variable, which it prints on the screen. Simple really (actually, a bit more advanced that we're expecting from anyone just yet, but I put it in for the terminally curious).

Where to next? I think we'll be using a form for gathering feedback on a website sometime soon, perhaps even for the greening australia assignment, so it would be useful to think about what fields you'd put on this sort of page, and how you might retrieve that information once it was submitted to the server.

Bonus Section

Try adding some radio buttons for the ultimate mission goal:
  1. inter-galactic domination or
  2. creation of a trade hedgonomy
These buttons will also have to be set up as an array, and will need processing similar to the species array.

Thanks to pvera for the picture: "Will code for food"

Image Maps

  1. Read about image maps and try the example

  2. Download and install Mapedit or some other image mapping tool

  3. Save the map above or find some other creative commons licensed map of Australia using flickrlilli (click on the image above for a full-size version)

  4. Make an HTML page with an image map linking each state (and the other countries) to their relevant wikipedia entries.

  5. Upload and link the page to your student portfolio

Image: "Australia and New Zealand 1788-1911" by hoovernj

Tuesday, May 16, 2006

Dublin Core

Yesterday my collendar like memory failed me when trying to think up a common DTD that people use when they're creating XML documents.

Today it came back to me: the Dublin Core is a set of descriptors (such as the title, publisher, subjects, etc.) that are used to catalog a wide range of networked resources, such as digitized text documents, photographs and audiovisual media. Often it gets used in XML documents that describe a collection of web documents or files.

This Wikipedia article explains the Dublin Core , and there's a user guide here - go ahead and create some Dublin Core metadata for yourself using DC-dot

Can you think why it might be useful to have this 'metadata' available about your web site's contents?

Thanks to Peter Morville for the pic

Sunday, May 14, 2006

Validating Website Performance

An assignment, due 29th May:

For the Validating website performance assignment you're required to write a report on the Web Development Toolbox CD you received last term.

Task 1 - Broken Links
Do a link analysis on the web pages, listing any broken interneal or external links on the CD. You will need to run this on a PC with an internet connection to test the external links.

Task 2 - Download Times
Look for any large files on the CD - those that would take more than 10 seconds to download over a dial up connection. What impact would these have on running the disk from a web server. Specifically, how long would these files take to download over a 56k modem? What could be done to minimise the wait for users with slow connections?

Task 3 - Usability
Create a list of 5 tasks for a typical user to complete. Tasks might be somthing like: "find a list of common graphics file formats and what they're used for". As far as possible, the tasks should be tasks that real users would want or need to carry out when they use the toolbox.

Take a volunteer and sit them in front of a computer running the Web Development CD. Tell them you're going to ask them to carry out a few little tasks for you. Make sure that you tell them it's not they who are being tested; reassure them that you're only interested in getting data about how easy the website is to use.

First, ask them if they would use such a site if it were available. You don't need to make it too much like a market research survey but a few questions like that would be useful.

Be sure to record their answers! If you like, you can use the CamStudio software, a video recorder or voice recorder to make this easier for you to review later.

Ask the user to carry out each of your tasks one at a time. Don't say anything to them, other than what the task is.

Watch them as they attempt to do the task. If they say anything, make sure you record it. Also be sure to record instances where they press the wrong button and finish up at the wrong page. Be sure to make a note if they get lost!

If a user does get lost, gently point out where they made the mistake, and show them the correct way to achieve the task.

Write a report detailing the overall outcome of the performance and usability project. You should recommend changes to the CD based on both the performance measurements and the usability tests.

XML, DTD, RSS and other 3 letter combos...

This week we're going to conquer those pesky 3 letter acronyms: XML, DTD and RSS.

Like html, xml uses tags to delimit data. Unlike html, it's very unforgiving of syntax errors - mistyping the tag name, mixing upper and lower case, inproperly nesting tags and leaving out closing tags are all sudden-death events for an XML document.

For the important bits on XML, please read through the following W3Schools pages:

Introduction to XML
What is XML, and how does it differ from HTML?

How XML can be used
Some of the different ways XML can be used.

XML Syntax
The strict but very simple syntax rules of XML.

XML Elements
XML Elements, relationships, content and naming rules.

XML Attributes
How XML attributes can be used to describe elements or provide additional information about elements.

XML Validation
The difference between a Well Formed and a Valid XML document and how a DTD is used to define the XML document.

which brings us to our next acronym:


XML's big trick is that you get to define the tags, which means you can use XML to describe just about any data.

So that other computers can understand what you're talking about, you need to give them some hints. Theat's where the DTD comes into the picture. A Document Type Definition dictates what the legal building blocks are for your XML document.

Once again, let's check out W3Schools for a DTD Tutorial

The good news:
We don't need to know how to build an XML document from scratch (yet).

The bad:
We do need to know how to create valid XML documents that conform to DTDs created by other people.

Here's one to practice on:

Google sitemaps are XML documents that describe websites so that the google search engine can crawl through them and include them in their search results.

Now, google will find pages by itself, but by using a sitemap you can speed up the process, and guide the robot to your best pages first. For your assignment: create a sitemap of your Bathurst TAFE web pages that conform to the Google sitemap specification - validate the sitemap and print the results, and submit them to me along with a printout of the sitemap itself.

Extra but interesing:
To add your own attributes to the XHTML specification you'll need to know how to extend existing DTDs.

One of the high profile uses for XML is RSS.

Really Simple Syndication has been used for years by web sites to broadcast the availability of fresh content; listing new pages in an XML file which special programs called aggregators can pick up and process, and tell real people about fresh content that they can read.

Like everything on the web, RSS has evolved. The important milestones are RSS 0.91, RSS 2 and the Google supported challenger: Atom. Read all about them on the Wikipedia

Coming up (next week?): we'll be looking at how to create a form and some script that will allow you to generate RSS 0.91 files for new pages as they're added to your TAFE website.

Thanks to kosmar for the
Web2.0 - extended mindcloudmap

Monday, May 08, 2006

more on the emerging web tech assignment

I'd hoped to have this conversation with you face to face, but a small accident this morning has kept me at home.

It's about the emerging web technology assignment I set last term. Frankly, I haven't seen enough evidence from anyone (except Matt), that you know the topics.

The idea behind having you blog and comment was that you could prove to me that you knew enough about each of the topics to either add some information, ask a pertinent question or answer a question posted by someone else - on each and every topic listed.

So, I need some more postings with solid evidence of subject mastery in them - failing that I guess we could go back to the tried and true: 'write me a 3000 word essay on the following topics...'

To be honest, the whole blog thing's a bit of an experiment, and has taken me more time than marking essays would have, so I'm more than happy to do the paper thing. I just thought it might be a better learning experience for you folks to read, analyse and comment on other postings, not to mention a bit less of a chore. The subject we're currently studying: Complex Markup Language Documents has an essay writing component too (about XML, RSS, DHTML and DTDs) - what would you like to do about this? More blogging or a straight up essay? Post a comment here to let me know.

In the meantime - please add some more content to the collected wisdom of the class blogs on emerging tech...

Sunday, May 07, 2006

Forms, CGI and PHP

Last week we played with some nifty form elements. If you missed the action, or just want to revise, the W3C have the definitive word on forms here, or you can find a gentler introduction on w3shools.

This week we'll try to implement a simple form. See if you can re-create the following useful web page:

Set the form's action attribute to point to dump-globals.php - which you can pick up from either here (if your outside the TAFE lab) or here (if you're inside the firewall).

Copy your new web page and dump-globals.php onto the bathurst-tafe web server, set the permissions, and test the page using both GET and POST methods.

If you have the time, you might want to see how to
create forms using CSS