14  Use the software

Usually software is made by developers that do not use the software itself for its intended purpose.

Software usually proceeds from an idea, requirements are gathered, it is built and tested, then released. That might be one process, or a series of iterations that add more functionality until the software is finished. It does not stop there because there may be functionality that was not put in the first version, or there are bugs that need to be fixed, so further versions follow. So, no matter which methodology was used to produce the original version, continuing production of versions amounts to iterative development.

Typically, in custom inhouse development by businesses, software development projects will have developers, under a technical manager, building the software, while business analysts gather the requirements and input from the business. While processes like Agile may have strengthened the business side of the process, software development is still mainly run by technical people whose daily tasks are not dependent at all upon using the software. This non-user bias is often why software fails to fulfil business needs, and users are unhappy with how it performs.

I was a technical writer for 25 years, writing user and administration manuals for software for industries including insurance, telecommunication, computing and superannuation. But while I got to document how to use the software, I still was not relying upon it for my daily tasks. Only those whose work satisfaction is heavily dependent upon the software are really qualified to evaluate the efficacy of it. Unfortunately, those real users are rarely the ones who provide substantive input into the design of software.

Often software development does not get user input until they submit bug reports after it is delivered. Those will be attended to with a promptness dependent upon their severity. But that only handles what is broken. Users may also offer suggestions, if they are even offered a process to do that. That means unless using some functionality is very annoying, everything will be left as is. But the degree of usability can be the difference between just being resigned to using software, or really enjoying using it.

Sometimes that will be because what might seem like minor functionality saves a lot of fiddly operations, which if a significant amount of time using the software involves using them, makes for a much more relaxing experience. For example, before technical writing, I used to do printed circuit board (PCB) layouts. We used two different software packages for doing that. Such work often involves moving tracks with 45^o bends around. In one package, that meant individually moving each corner and making sure they lined up again afterwards.

In the other package, it just involved clicking on one corner and moving it along, while the software made all the other adjustments to the track automatically. When trying to move dozens of tracks in multiple places to squeeze in multi-pinned components, that simple smooth ability to change each track made using the software much easier to use. Enough of such flourishes and the software becomes enjoyable to use, just because it allows more concentration on what is to be done, rather than the details of how to do it.

Other times, it can be about what information is displayed, and how helpful it is at that point. When designing the product, I was putting in a lot of what I thought would be helpful status information, such as the Work list page showing how many outgoing and incoming links there were for each article, and how many files they used. I thought that it might be useful when determining whether to delete an article to quickly see the extent of its dependencies. However, after several years, I removed them because I did not use them once, being too obtuse to remember what they were for.

These instances demonstrate why it is necessary to actually use the software, or at least really encourage users to provide such feedback. Sometimes even offhand remarks can open a door to adding useful functionality. We can always find excuses not to add functionality, but we need to be willing to sleep on it. It can be that a suggestion may be a prompt to adding a more generic functionality that covers the use case suggested, but also others not thought about when originally designed.

Sometimes it can be that adding some functionality tips the balance of the internal design from a bunch of disparate processes with their individual data requirements to a centralised data store. Having to periodically modify such structures was why the rules XML file came into being. The field editing parameters used to be in arrays. The new element structures were in the PHP as strings. Having the rules XML put them all together, and ended up being significantly expanded for use in functionality added later. Adding new elements became significantly easier and simpler.

Working websites have a lot of different elements that have to hang together, not just initially, but as the content of the site evolves. A critical part is links as they are the backbone of what makes the web useful. However, links can become dead, either because external sites have disappeared or reorganised, leaving dead links, or the site needs some reorganisation, also leaving dead links. Thus means of tracking dead links, or even automatically fixing some of them becomes useful. Such things are obvious, but usually not included in web software, despite it being inevitable.

Over the time of designing the product, I have added more functionality that identifies dead links, and some that fixes some of them, or at least is more specific about where to fix them, such as bidirectional cross-linking between the items in the Linked from lists of articles and categories and the specific items containing the source links. All this is a result of using the product and finding out where there are gaps that it could cover.

The Work list page includes the hierarchy of site structural elements which can be used to drill down to a particular article, but it requires remembering its subsite and category, which gets a bit fuzzy after a few years. After many times of failed drill downs, I decided having plain alphabetical lists of articles and categories would help. While the search facility is useful for finding which articles contain specific text, that is geared towards site visitors than managing a site. So, along with the lists, I included a more literal search facility to make the Find page.

But it also includes the ability to search using XPath, which allows much more sophisticated searching by element types and their relationships, rather than just by content. This proved very useful when I needed to change the internal structures for some elements, requiring going into each article to fix them up, as it could give me a list of all articles containing the specific attributes or element relationships that need changing.

The Done column was added so that I could see which articles I had edited, such when I went through all articles on multiple sites to covert contractions like don't into separate words because they are not as easily understood by non-native English speakers. While I have done such things using the search facility and its resulting lists of links, the find method kept it all in the managements pages with the advantage of tracking completed editing.

Using the software and being able to have direct contact with other users enables designing and refining software so it is far more useful and usable. The product was born out of fulfilling a personal need, and developed over several years as those needs evolved, triggering adding functionality to handle such changes. In this way, it has grown into a product that really manages the dynamic nature of websites, rather than just creating pages, hoping that they do not need editing or reorganisation, if that was even thought about when creating them.

Whatever we create with software evolves, and if the software is to be truly useful, it must facilitate that evolution. Most software can be designed to handle the create, read, update and delete (CRUD) of individual entities, but good software will facilitate making their relationships visible and modifiable, with facilities to prevent them being broken, or at least indicate when those relationships are at risk or broken if prevention is not possible.

Users know what they expect software to take care of, so we should be an extensive user of it, and get other users to provide feedback, if we want to make it shine.