1. Picking the philosophy

While everyone would like their product to be perfect, finance and marketing can force some pretty drastic compromises.

Building products can be expensive, and so getting them to market quickly can bring returns on the investment more quickly. The extreme is selling the proof of concept as if it is the complete product, which subjects all purchasers to having to deal with a flaky product with many bugs. To me, a product should be production-ready, in that it should be built to be stable enough for users to rely upon rather than having to find workarounds for its inadequacies.

I was not wanting to spend the rest of my life fixing up bugs, so I decided that the product had to be as fully working and as reliable, usable and consistent as possible. Being a pensioner with low overheads for the last few years has meant that I did not need to rush the product to market, so could take the time to make it the best it could be.

Refactoring is changing the design of a product or component when there is an opportunity to simplify it or make it more useful.

Designing is about making a making something fit for purpose, but that purpose can change as the users make suggestions, or even as design proceeds. When faced with time constraints, there is the tendency to just do the bare minimum necessary to accommodate the changes. While this may solve the immediate issue, it often adds complexity that hinders the future ability to make such quick changes.

A product undergoes the most changes leading up to the first version, and between the first and second versions. Architecting it so it has the most generic and flexible structure is the first step in, but that does not always deal with future changes. Refactoring is taking the time to do limited redesigning when the need arises. It is both a reactive and pre-emptive process.

I refactored many parts of the product as I went along, especially if they lead to more flexibility and adaptability, which usually enabled more opportunities for refactoring, just because they allowed it to be done more quickly. For example, I didn't realise how easily I could create new elements until I centralised many rules into their own XML file. That spurred adding many other rules, and even the proforma skeletons for new elements, resulting in a reduction of PHP code and complexity within it. There are only about 10,000 lines of PHP code used.

While a product may be useful, how easily it can be used makes the difference between whether it is enjoyable to use or not.

When products are rushed to market, it can take lots of customer feedback and several versions to get a truly usable product. While a product that actually does what it is supposed to do should be a given, it is the care taken in design and implementation that gives a user a sense of confidence in the product. It is only time that allows a lot of the little kinks to be ironed out.

Smallsite Design was being used to render several real websites years before any management or editing facilities had been built. It took some more years from building the login page to finishing the product. This provided ample opportunity to shake out bugs and improve its look and usability. That is not to say that it is completely bug-free or never will have any, as any future changes can introduce some, but the long process and real-world use has made it a mature product at release.

The long-term usage enabled me to see how I could tweak functionality to be more user-friendly and consistent, as well as new functionality, such as the sequence element, that could be really useful. It also enabled me to see how a person with autism could handle using the product, improving the usability and what changes to make for accessibility mode.

I wanted to make the product less reliant upon third parties, and that includes in what the product is designed to do.

It would be ridiculous to not use the product for the product documentation, being that it is for building websites, but I extended that to add whatever functionality I would need to support the product, as long as they didn't introduce new dependencies. I figured that if I needed them, many others would find them useful. That includes being able to be used for online help and even fancy formatting for buttons for prominent calls to action. The procedure article layout and functionality is something I originally developed for use in Windows help 25 years ago, and used in many contracts since.

I had considered adding appointment booking with PayPal integration, which is what I had already done simply with a previous site. However, PayPal is not really suitable for an international product, as it involves manually setting up and maintaining multiple tax rates. A quick search turned up over 20 online booking sites doing almost exactly the same thing, while also handling payments, so I did not need to reinvent the wheel there. I think when it comes to handling money, people are more trusting in a large centralised payment gateway subject to government scrutiny than a small website.