8  Limits

Smallsite Design is meant for those who want to build a site for managing a body of knowledge, whether that be a subject, a product or what a club is about.

These purposes do not continually add content, but build up to enough to cover the subject or area, and then refine and update, occasionally adding and deleting articles as circumstances and the subject evolves.

These are the sort of limits imposed not by the product, but by what site owners will likely build up to for their purposes. Smallsite Design can accommodate several times these, though at thousands of articles, things might slow down some, depending upon the server's power and bandwidth. The target site owners will likely only be using low-end shared hosting, purely because they will not be expecting their sites to be so large.

Because of the expected site sizes, and a design goal of making sites portable between hosters for those not really technically-inclined, Smallsite Design uses XML files, rather than a database, to store a site's data. XML shares a large part of its technology with HTML, and XSL, which is based upon XML syntax, is used to transform the XML into the HTML to be sent to browsers. Sites are archived into a single ZIP file which can replace a site or be partially imported into a site.

There are several hundred locales included in the Unicode Consortium's CLDR supplied with PHP. Most sites would only be using one locale, some may use a few, though online help for a product may reach to 10-20, depending upon the translator resources available to a site owner. Each article file contains the text for all locales, but only the text for the locale that a visitor is using will be sent to their browser.

Smallsite Design provides categories to group articles, and subsites to partition content for different audiences.

Again, there are no hard-wired maximum limits for these, but rather than being constrained by the likely content usage, the numbers of these is more likely to be defined by visitor usability. Both categories and subsites are meant to allow some partitioning of the content in a way that is suited to it. This does help visitors to not be overwhelmed by sifting through a hundred or so articles, but by a top-down structure, much like a table of contents for a book, that can be drilled down through to get to particular topics of interest.

However, people do not like too many options to choose from, so there are some limits that are reasonable to aim for when constructing sites. Category pages are provided which list all the articles in a category. A reasonable size for looking through would be 8 to 20 articles. At a higher level, there is a page that lists all the categories in a subsite. However, because they are at a higher level, too many choices may not be helpful. 3 to 10 categories per subsite is a reasonable number to choose from.

There is also a page listing subsites, but they are also listed in the navigation bar at the top of pages, so 2 to 5 per site is reasonable, though most sites will have only one. Multiplying the numbers out from these, there could be anything from 20 to 1000 articles, and 3 to 50 categories per site. Of course there will be varying numbers of articles and categories in their respective parents, so numbers will tend to the lower end on average.

Every subsite has a default category with the subsite's home page in it. When Smallsite Design is installed, there is a main subsite, with its default category and bare-bones home page. See Edit the home page and Planning a site for what to do from there.

Special navigation pages – which include home pages – are provided that allow up to 8 cards, each with a heading, picture and short synopsis that enables clear visual choices to be made quickly. A level or two of these finally linking to category article lists can provide an easily navigable way for visitors to drill down quickly to what they may be interested in.

This is where there are some hard-wired limits, but suited to the type of content in the different article types.

In general, limits are defined for the type of usage that each article type will likely be used for on the sites built. For example, while a general article could be built to hold the content of a book, a test only allows up to 20 questions because no results are recorded, so they are not meant for serious in-depth evaluations. Lower limits are those at which any less would be overkill for the little content involved. There is no point in having a test with one question, as a paragraph should be able to handle that simplicity. Upper limits are generous enough for the type of use expected.

Many bowsers have a reader mode that simplifies the page layout to just the main content to reduce clutter.

Reader mode is meant for those sites that provide articles but with lots of ads or other distractions. They will only show the main body of the article, formatted for better reading, and so will override many of the CSS styles for the page to make them less gaudy. Also, the pages are made passive as all buttons are removed, though basic multimedia elements remain intact. Some browsers will not show a button for reader mode if the page is already uncluttered enough.

Unfortunately, readers do not handle page elements that are not plain vanilla HTML very well, and so will expose parts of them that may not be visible. For example, Smallsite Design lists hide the normal bullets and substitute them with links to make navigation easier for those who use their keyboards extensively. In a reader, the hidden bullets are exposed making each item have two bullets.

Some elements are specially formatted, but that formatting is lost in a reader. The contents of a program element will no longer look like monospaced and coloured computer code with a bordered grey background, but appear like a whole bunch of single-lined paragraphs, totally obscuring its purpose. A Sequence element is unusable as there will be no buttons, but the hidden parts and skip tables are exposed. Basically, reader mode can make a lot of useful elements appear like roadkill.

Reader mode may also format the page in an accessibility mode, with extra line and paragraph spacings, erroneously assuming that this works for all people. However, what is good for some people like those with autism or dyslexia does not necessarily work as well for who do not have such neuropathies. Accessibility is not about making everybody use the same formatting, but catering to different groups who might have mutually-exclusive preferences. Smallsite Design does have an Accessibility mode that provides a lot of the formatting that reader modes provide.

For site visitors, Smallsite Design pages are already as uncluttered as they can be as no third-party elements like ads can be embedded. Complex pages and even fairly plain text pages will look better and be more cleanly navigable than when in reader mode. Of course, a page can still be made to be cluttered, but a reader will likely mangle many of those elements.

Smallsite Design can be used without JavaScript, but there are some instances where it provides some enhancements.

Pop-ins are disabled while editing.

Modern browsers will have JavaScript enabled by default, though some accessibility tools may modify or disable it. In Smallsite Design, JavaScript is included in the page and not in a separate file, and coupled with modification-prevention measures and the disallowance of embedded third-party elements that may have JavaScript code, malicious code attacks are prevented. Note that some browser developer tools or extensions may add JavaScript.

Smallsite Design relies extensively upon CSS for layout and selective display of page elements.

For sighted people, disabling CSS will make pages visually broken, and for all users may expose some elements that are not normally shown, cluttering up the page. For proper functioning, never disable CSS. Styles are not prevented from being overridden by some accessibility tools, and while the fluid design will accommodate many of those changes, some may cause overflows in elements like tables.

In Smallsite Design, CSS is always included in the page, and not in a separate file. This prevents the flash of white that may occur when there is an excessive delay until the CSS content in a separate file is able to format the page.