10 Facilities
While a product has some core functionality, there are many facilities that it can also provide.
Smallsite Design's focus is upon the written word, but all the normal HTML elements like tables and lists need to be created. Beyond those, I added a few elements that I thought would be useful, mainly because I needed them to use in the product and help documentation.
The button element provides a way of doing a POST request to a site rather than the normal GET request of a link. The diagram element provides some basic graphics capability suitable for diagrams and visual navigation. The sequence element can replace a lot of videos that are basically slideshows with commentary, enabling them to be part of the site rather than hosted elsewhere, and with a fraction of the bandwidth required. See Elements for a full list.
The different article types provide particular functionality that would otherwise require HTML and CSS knowledge to create. The general article type includes sections and subsections including their child navigation bars, but these are not common in site-builders. Procedures include two levels of steps, but can also be interlinked with others in a hierarchy up to 10 deep. Tests help visitors gauge their understanding while allowing results-dependent comments to help them. Policies and contact pages round off the offering.
We then get to the facilities that enhance operability. Banners can be created and their text can be edited and sized. A logo can be inserted for familiar branding, or a full-width backdrop image can be used, with or without overlay text. A site can be archived or overwritten by another archive, or just some elements can be imported from it. Redirects can be set up for individual pages, grouped by prefix, or the whole site. Links can be checked for errors.
Any article can be cloned as the basis for another article, but an article can also be created as a template to be cloned from, but is not part of a subsite or category. They can also be repositories of commonly used blocks that can be cloned and edited.
Most operating systems offer a sort of clipboard. These usually only hold one item at a time though they might hold both formatted and unformatted versions of it. Smallsite Design has a range of complex elements that such simple mechanisms know nothing about. To handle cloning and moving elements around in a flexible way, I created what I call spikes, after the old bill spikes that were a tall spike on a base, onto which obsolete invoices were skewered. An element can be put on a spike or its children can (unwrap). Spike items can be appended to, inserted after, or replace another element.
I originally developed an overengineered statistics facility that showed the referring and referred pages for each page to three levels deep. While it may have been useful for SEO afficionados, it was just too complex for the target audience. In the end, since most cPanel-based hosting includes several statistics packages, I really only needed to provide a list of the pages that were actually read, most popular first, which is something that most packages do not give. For those sites with multiple locales, each locale's popularity is included.
I contemplated adding a comments facility, as I thought that it would be fairly easy to implement. However, I decided not to because they have the potential to be toxic for a site, and so need a lot of time to properly curate, which can take significant time from content creation.
Originally, search was simply using the site: filter with a search site like Google. However, after discovering the most search engines ignore most of a small site's pages, a home-grown one was required. While it is not as sophisticated as Google, at least it covers 100% of the pages, compared to their less than 10%, allowing visitors to find all that a site has to offer. Since Bing now covers 100%, and DuckDuckGo uses Bing and has an attribute to restrict searches to a site, using an external provider is now an option, though their filtering by site is still flaky. See Adding search.
While we do not want to have to continuously second guess all our design decisions, it can be beneficial when modifying functionality for a specific reason to reexamine some of the original decisions about how it works or is used, and so lead to some better operation or workflow. I do not know why I did not see how search did not need to be multi-step years ago. In the past, every public page had a search field among it links at the bottom of the page, with a 🔍 link in the top navigation bar to the text field of the form. Clicking the
What I did not ask myself earlier, especially when designing search, is why bother having a form at the bottom of the page, but just go straight to the search page, especially since both processes require a click to get to the field. The result of the challenge is that searches are only carried out on the search page, and the links area at the bottom of the other pages is less cluttered. Like before, the link in the bar of the search page goes to the field.
A facility I added halfway along was multi-deleting, where, while editing an article, individual child elements could be selected by checkbox, and then deleted all at once. Worked fine, but it actually used a checkbox inside a button, which is not technically allowed as it is nested active elements. While trying to find another way that was allowed, too many odd technical situations emerged that meant either sticking with a disallowed situation, or abandoning the multi-delete.
While browsers can be forgiving of such situations, that does not means they handle them well. For example, in generating HTML, sometimes an element may end up being erroneously empty. The simple way for a browser to handle that is to just let it sit there as an empty element, and probably no one would notice. However, browsers treat it as open-ended and proceed to stuff it with as much of the following HTML as they can. Somehow, that can end up as half a page being one big link with hundreds of supposedly non-allowed multi-layered tag embeddings.
Allowing browsers to be creative in this way can adversely affect how the product is viewed, so it is better not to risk it. That leaves a decision as to whether a facility can be done differently, or just abandoned altogether. I had contemplated including such multiple-selection methods for other operations, such as adding elements to a spike, or for the
I rejected those at the time because most users would probably get mixed up, and the process of checking multiple checkboxes can be fiddly and one wrong click can cause the whole process to be abandoned. I had used the multi-delete facility on many occasions, and it was also fiddly, and a mis-click did drop the whole operation. If I as the designer was having issues, perhaps most users would have a much greater amount of problems, so I decided that not enough users would actually find it useful and reliable enough, so I dropped the functionality very late in the process.
After removing the multi-delete facility, I rediscovered why I used it many times, and that was when editing rich-text elements like paragraphs. A