Core functionality finished!!

When I was young and daft (my daughter says I’m just old and daft now), I enjoyed a lot of sport, running and cycling and climbing being my personal favourites. In these disciplines (and I’m sure in many others) you can be so involved in the race or the climb, that reaching the end can come as a surprise. Sort of a “blimey, where did that come from?” type of moment. Well the same sort of thing has happened with Rapidsite 3.

“What does it do George? what does it do?”

We now have a working prototype that will produce XHTML 1.0 compliant web pages, using table free designs with the content, structure and design seperate. This means that the pages should degrade well in alternative access technologies including mobile phones, PDAs screen readers, etc, as well as older non-conforming browsers.

Obviously the actual presentation effects created in these alternative platforms will depend upon the style layer, but as this is separate from the other layers, appropriate themes can be applied to the website without affecting the information within.

Flexible site structure.

The final part of the puzzle was to re-visit the Page Creator. Although it appeared finished last week, upon further inspection it was found that it had some failings, mostly to do with the removal of pages and the movement of pages with child pages to another part of the site.

So following a re-study of some articles on the modified pre-order tree traversal algorithm method used to build the site architecture from a flat file database, I realised the problem. Essentially, every page ‘knows’ where it is in the site structure because it ‘knows’ who it’s parent is and who it’s siblings are. Each page also has a rank to say where about it should sit within the menu it belongs to. The problem we were having was that when moving a page from point A to point B, we could make it move nicely and create space for itself at point B, but the hole left by it’s departure from point A was not closing up. We can illustrate this with the use of some ducks.

As we can see the ducks all start out nicely spaced, but what if we want to move duck C to in between duck E and duck F? Well three things have to happen, first ducks E and F have to move apart to make space for the incoming duck, then duck C has to move into the space create, and finally ducks B and D have to move together to close the gap left. Well we could get our ducks to do the first two actions but not the last, so as a consequence duck F was being pushed off the end of the log, and large gaps were being left between ducks every time one of them moved.

Finally we realised that the only way to fix this issue correctly was to re-parse all the ducks after a major move, this was not necessary for additions of new ducks, as no holes were created during that process, but for moving and deleting ducks we needed to go through our whole flock and shuffle them back into good order. Now obviously this is a bigger job than just moving two ducks apart so we don’t want to do this to often, so we’ve worked out the minimum number of activities that will require this, and we only fire this method for those activities.

Now we break it.

So now we have an alpha release, we hand it over to Stuart, who has an amazing ability to break software. We’ll let him find all the ways to break the application that we never thought of and then mend it. While he’s doing this we’ll develop some of the SEO (Search Engine Optimisation) tools that we want to produce for it.

Once both of these stages are complete, we will revisit the theme engine to check the parameters that need to be specified for the theme designers to work by. By keeping the structural code away from theme designers we can guarantee the quality of the code produced (nothing personal theme designers!).

After all that lot, we are approaching a beta release and some usability testing. Exciting stuff.