7  Implementation order

There are many ways to develop a product, with what works best dependent upon skills.

I had been part of a project that used Rapid Development Methodology, which was an iterative process that developed front end screens first, then the logic behind that, and then the backend processes to support those screens. Each set of functionality went through that process. That is basically what I ended up doing with the product. Using normal visual program development tools like Visual Basic meant screen mockups could be done easily. It is slightly more complex with HTML and CSS, but they are enough for mockups.

Typically, web design logic behind a page uses JavaScript (JS), but since I wanted to minimise its use, I had to go a different route. Instead, I developed the XML storage structure and XSLT transform for a page after the mockup. On many, I did the whole stack at once, often because it only took a couple of days of iterating rapidly to get to what was close to the end construct. In this way, I could build working sites that required editing the XML storage directly, enabling me to occasionally tweak the look and feel.

During the building of the various pages, I constructed the stack for the various HTML element renderings, such as footers, navigation, tables. This was a very dynamic phase as I made a lot of decisions about what to include, only to drop them later on as a result of what I found worked on the working sites as we fleshed them out. My spouse often asked about whether some facilities could be included, and I ended up including many, but not necessarily as they suggested, usually because I could see that a more generic version of them could be more useful.

Finally having working sites meant I did not have to rush development of the management pages, so I could start at the beginning with the login page. From there it was the Work list, then through the pages for the core elements, like subsites and categories. At the tail end were the various administrative and facilities management pages. I had a JavaScript program to push updates to a site, so I could delay having the page to pull the latest version.

The overall process is that all work is sent to the development site, which is no different to other sites hosted on the same server, but which no one else really knows about. So there is no functionally different development vs production environments. If my testing shows that the functionality works, the new version is uploaded to all the sites. The process allows changes to be made and uploaded in less than a minute, so that I can verify each facet is working before incrementing its functionality, making it continuous integration. It also means I can debug in the same fine-grained way.

I left the editing page until very late in the process because it was going to be critical to how well the product would be to create actual content. I always saw that because the HTML of pages was hierarchical, having the same structure for managing every type of element was essential. This proved extremely useful as my first attempt produced a look and feel where the page itself was overshadowed by the page structure. It was about as far from WYSIWYG as could be. But by changing how that element structure block worked, I could build a view that revealed more of the actual look of the page.

With one more iteration of that block, I came up with the final form that makes the page look like what would be published, until an element is clicked upon in a particular place, allowing the block for that element to be shown. This was a dramatic transformation that happened in two iterations principally by editing how the core block operated. Of course, there was a lot to make it work, especially with the CSS, because in the editing page, there was extra HTML within each element that did not play so well with the CSS that pages used for elements when they did not have the editing extras.

Having conquered the management and editing pages, there appeared only the user interface translations to go. I even offered a free license to some people I knew, but none had a need for a website at that time. While there was the potential to be used, with every bug I found, I was in a mad panic to remedy it. After a month or so, I withdrew the offer as I realised that I needed to focus on making sure that everything was as bug-free as possible, even if only for my own sanity.

I was not really looking forward to the translations, so I was grateful for suggestions from my spouse or opportunities for adding functionality. One of those was the sequence element which came out of my spouse doing meditations. It was extremely wasteful to have a whole audio file of about 20MB for a 15 minute meditation when there was very sparse vocals and the music was such that it could easily be made of a looped short clip. Thus I spent a month or so building the first version of the element. The second version added a skip facility along with a pointer. See The Sequence element and Audio API for details.