2. Planning a site
Smallsite Design provides a few structures to help with fleshing out a workable site. To use these effectively, some planning may help.
The three basic components of a site are:
site Hosted domain└─ subsite Has own home page and navigation└─ category Group of related articles└─ article Where the real content goes
When installed, there is already a main subsite, complete with its own default category, and in that a home page. The site is operational and is in its minimum configuration, but this is not what you bought Smallsite Design for, so let's see what we can really do with it!
Subsites△
Subsites are like a self-contained part of a site with their own navigation and home page. There is always a main subsite.
Each of the main elements has an identifier (ID) that is used in URLs, so the initial layout of the main subsite, by ID, is:
main Main subsite└─ main Default category, with same ID as its subsite└─ h-main Home page, with the subsite ID preceded by h-
Subsites and default categories are not directly accessible by a path, but through their home page, such as /art/h-main/, though the main home page has the special path of /.
If a site is for a single purpose, at least in the way you see it, then no other subsites are needed. However, if you want the site to cover areas that might attract different target audiences, whether that be in the topics covered, or by differences in depth of treatment, then extra subsites can be of benefit. That is because they offer their own home page and navigation, making it easier for visitors to stay with what they are interested in.
Extra subsites need their own name, from which their ID is derived, so a name of Buying land produces an ID of buying-land, leading to an ID structure of:
buying-land Buying land subsite└─ buying-land Default category└─ h-buying-land Home page
The name here was in English, but as long as the name can be rendered in Unicode, it can be in any of hundreds of the world's languages. Note that users' browsers also need to support the name's Unicode characters, otherwise the name appears as a bunch of small boxes! Check the browser versions your visitors are likely to use to ensure names are rendered properly.
As a site develops over time, some extra subsites may have been created. If the focus and audience of the site has changed over that time to favour one of the subsites, it can be swapped with the current main subsite to become the new main subsite. The URLs for the articles and categories will not change, except for the home pages. During the swap, a new name for the former main subsite will be required and from which a new subsite id will be generated and prefixed with h- to be used in the new path to its home page.
Categories△
Categories are a collection of related articles, and have a page that lists them all.
While you could just put all articles in the default category, they cannot be listed from there. Making a category means that all the articles in it can be listed, so a category name of Evergreen trees would lead to an ID of evergreen-trees whose articles would be listed using a path of /cat/evergreen-trees/.
To get a list of all the non-default categories in a subsite, the path is like that for a single category, but using the subsite ID instead, such as /cat/buying-land/, even though that would appear to be what we would use to access the default category, if we could.
The order of articles listed on the category page can be alphabetical, reverse alphabetical or numeric. When numeric, the position number is listed before each headline in the list, but also in the heading of the article page itself. Articles of a numerically-listed category also have links to the previous and next articles in the sequence in a special navigation bar at the bottom of the article.
Articles in a non-default category also have a special navigation bar above the article header, with a link to the category listing page, preceded by a Categories link to the subsite's category list. Also included are subsite category and article totals. If the article order is numeric, Previous and Next links to the respective articles in the sequence are also shown.
Articles△
Articles are the repository of the information the site is providing. There are several special types that help build a useful site.
Article IDs are derived from their headlines, prefixed with their type identifier, except for special subsite articles which use their subsite ID instead.
| # | Type | Prefix | ID from | Description |
|---|---|---|---|---|
| 1 | General | a- | Headline | General purpose with sections and subsections |
| 2 | Navigation | n- | Headline | Navigational pages, because they allow card arrays, a catalog or an image gallery. Limited content otherwise |
| 3 | Procedure | p- | Headline | Procedures and instructions with steps, substeps, and learning notes |
| 4 | Test | q- | Headline | Simple multiple-choice questions for helping readers gauge their understanding of a topic. Score-dependent comments can be added. Results are shown, but not retained |
| 5 | Glossary | g- | Subsite ID | List of special terms used in the subsite |
| 6 | Policies | l- | Subsite ID | List of the policies applying to use of the site or its services, including privacy |
Home pages are a navigation page, but with their ID built from a h- prefix to their subsite ID. Along with the Glossary page and Policies page, it is in the subsite's default category. Another subsite-specific article is the contact page, but it is built from the information supplied in the Contact section of the Subsite page. Because default categories cannot be listed, links to these subsite pages can be enabled in the Site links row of the Links to section of the Subsite page.
Articles can also be placed in a default category, such as an About page that would be the first slot in the subsite navigation bar. Navigation pages in the default category can serve as mid-level navigation with cards, where they are fed by cards on the home page and feed to category pages or other pages that are suitable to be a signature page in a category.
Locales△
A locale is a combination of a language, optionally a script, and a region, usually a country. It is used to specify what character set is used and how numbers and dates are formatted.
Smallsite Design allows content to be shown for multiple locales, though most sites will only use one as its master locale, which will typically be set for what most of the target audience will be used to.
Careful consideration must be taken in selecting the master locale, because while it can be renamed to use a different region/country, its language or script cannot be changed, as that could make all current content at odds with the rendering script and direction required by the new locale. Neither is it possible to swap another locale with the master, due to the deep internal dependencies tied to locales. Hence the need to select a widely-used language for the master locale so that it is unlikely to need changing as the audience or your focus for the site changes.
If wanting a site to cater for a particular group that uses a little used language, compared to the world, preferably use a widely used language for your master locale and the lesser-known as a secondary locale. This will make the site accessible for most users while catering to your special visitors. For example, if providing a site that describes Cherokee heritage, preferably use English (United States) [en-us] or even English (World) [en-001] as the master locale to cater for the widest possible audience, but offer a secondary locale of Cherokee (United States) [chr-us] for native Cherokee speakers. Of course, other locales can be provided for speakers of other languages.
To input text for a locale, a means of generating the required character codes is necessary, being either a physical or on-screen keyboard. If the latter, it will have to be installed into the operating system (OS). If only editing text for the locale in Smallsite Design, a language pack for the locale – which provides all the OS user interface text – is not required to be installed for the OS, but may be required to be added to the browser, along with enabling spelling and grammar checking for it.
The user interface (UI) language selected for a locale is initially derived from it if it is one supplied with Smallsite Design, otherwise English [en] is used. If wanting another UI language instead, select from those available. Just to be clear by using an example, if selecting Arabic (Egypt) [ar-eg] as a locale, Arabic [ar] will be automatically selected because it is included as a UI language with Smallsite Design. Alternately, if Cherokee (United States) [chr-us] is selected for a locale, the UI language will default to English [en] because Cherokee is not included as a UI language, but can be changed to another available UI language.
Typically, after adding a locale, ensure all non-main subsites and categories have had all their texts defined for that locale before enabling it. For articles that do not have that locale enabled until their texts have been translated, they will fall-through to an enabled locale, and show a message under their header indicating that the locale is unavailable and which one is being used for display. Once translated, enable the locale in the Locales row of the Details section of the Article head page so it will be visible. All links on the page still use the original locale to maximise locale continuity while traversing the site.
The locales available are dependent upon what is currently available from the Unicode Consortium. There are some languages, like Guarani, that are spoken by millions but are not yet available as locales. Each new version of PHP uses the latest Unicode locales, so hopefully the missing locales will appear over time. Some languages, like Esperanto, Latin and Sanskrit, will never have locales, but they can be selected for the user interface text, and are able to be used in content, provided their script is supported in the browser.
The layout direction of pages is dependent upon the locale, not the UI language. The UI text will render in the correct direction, but will be aligned according to the locale's direction.
Hierarchy△
Locales can be made into a fall-through hierarchy, with the master locale as the root.
In creating article content, the content for the master locale is created first. The master locale is also the only locale where block elements can be created and moved. All others only allow the text and internal structure of rich text blocks to be changed and reordered to allow for the grammar of the locale. By default, all non-master locales defer to the master locale text if the content for the locale has not been translated and enabled for an article.
However, a local can be specified to fall-through to another locale by selecting that other locale as its Next locale. This then defines the order in which translations must be performed, with those furthest from the master locale done last. After translations have been done, all subsequent edits can be done in any locale order as they may only be corrections for specific text for a single locale.
Some considerations for determining the hierarchy structure are:
- a.Not all locales need to be a part of the hierarchy, falling through to the master locale directly.
- b.The fall-though order is applied site-wide, not at the individual article or subsite level.
- c.Translating may depend upon the resources available. Those articles that might have to wait will be better falling-through to a locale that is still understood by the audience.
- d.Languages with multiple scripts should be set to fall-through like a mini-hierarchy.
- e.Put more popular languages closer to the master locale.
- f.Put languages that are substantially based upon another further away from the master locale, so that those familiar with the derived one will likely still be able to understand the base locale version.
Languages, such as Chinese, Serbian or Uzbek, which have multiple scripts are perfect candidates, with the most popular within the intended audience for that language closer to the master locale. Those articles that have not been translated into the less popular scripts will fall-through to a locale with a script that the audience is still likely to understand, rather than the master locale which might be unfamiliar to them.
Note that some of the locales for a language might not have a user interface language with the same script available, defaulting to English instead. That might be able to be changed to a script that is available for the language.
Element fall-through△
Fall-through also works at the individual block element level.
At an individual element level, the locale fall-through is typically for eliminating redundant duplication of text where there might be different spellings for some words between different locales. For example, if the main locale is en-us and another is en-gb to cater for readers who use British spellings and that falls-through to the other, for those paragraphs that don't contain any words with different spellings, it can just fall-through to the en-us version. Besides spellings, another reason to have different text for the same language can be idioms or expressions peculiar to specific locales.
However, unless having specific reasons to do so, just use one locale per language and use your normal spelling, which for English would be en-001. The web is forcing people to be less finicky about reading only in their preferred spellings. If the browser flags your spellings as errors, but you know they are valid, add the word to the browser's dictionary. Hopefully, browser dictionaries will eventually have all spelling variations included for the en-001 (world) locale.
Another scenario for element fall-through is if an element inadvertently wasn't translated. The fall-through process allows some text to still be there, even though it may be in another language or script. It may look odd, but at least most readers may be able to read it so that the narrative doesn't have a gaping hole in it. Even if the substituted text's script has a different rendering direction, the text will be aligned to the page's direction so that it is still in the location where the correct text would be, rather than on the other side of the page, so maintaining visual continuity.
When translating for another locale, there is a special 🗗 button that clones the content of a rich text element locale's Next locale. That will usually consist of one or more inline elements that can be individually translated and rearranged according to the grammar rules for the new locale.
Visibility△
Various elements can be hidden from public view until ready.
Non-master locales can be disabled so that they are not listed. All aspects of them are still editable in management, but their IDs will be struck through to indicate their status. They cannot be disabled if used as the fall-through (Next) for another locale. All texts for subsites and categories should be translated for a locale before the locale is enabled. For new articles, non-master locales are disabled to allow time to translate them. Until then, they will fall-through to an available locale, showing a highlighted message with the original and which one they are rendered with. All links on the page will use the original locale to maximise locale continuity while traversing the site.
| # | Visibility | Description |
|---|---|---|
| a | Hidden | Not publicly visible or accessible. Initial visibility when created |
| b | Unlisted | Accessible but not publicly listed |
| c | Listed | Publicly listed and accessible, including in site maps |
Unlisted means that an entity or its descendants are accessible, in that they can be viewed if their URL is known, but will not appear in the Subsites page, Categories pages or Latest articles page, nor in the Site map, so search engines will not list them. This makes unlisted entities suitable for temporarily making information available for those who are given their URLs. It is not meant to be secure, but a hide-by-obscurity means of limited exposure of information. While links to them can be created from more visible pages, those links will appear as plain text ʘ?ʘ on those other pages unless they are also Unlisted.
The entities that have no actual visibility setting, but behave as if they do, are:
Some things to note are:
- a.Subsites themselves have no visible text except for their name, and are never directly accessible, so they link to their home pages and use their descriptions on the Subsites page.
- b.Per subsite articles, like the Glossary page and Policies page, are kept in the default category, but are only publicly listed if enabled in the Site links row of the Links to section of the Subsite page to appear in the Subsite links section of pages.
- c.Home pages are in their subsite's default category, but their URLs are exposed by the Home button in the subsite navigation bar on all other pages, as well as being the URLs for subsites in the Subsites page.
- d.Any other non-hidden pages in the default category must have an explicit link to them from a Listed entity to be publicly available. Such links can be from a card, catalog item or gallery picture in a Navigation article or in a Related articles list for an article or subsite.
- e.If a category is changed to Unlisted, it is given a Password and will show it and any of its articles as Unpublished. The category and its articles will not be visible unless the password is in their URLs or entered on a Restricted access page. They also have an Expiry date, after which they will become unavailable.
Editing is mostly what-you-see-is-what-you-get (WYSYWYG) but by pressing the View button in the management navigation bar, the page will be displayed exactly as it would be if released, including theme colours, regardless of its actual visibility, though it has a highlighted warning at the top about its status. It is only available for 30 minutes, but should not be refreshed if it is no longer the latest View for a user.
Most elements in an article body can be manually disabled, though many are automatically disabled because they are incomplete when created and must be edited to have correct text or a minimum number of children before they will be automatically enabled again. Manually disabled elements will not be publicly displayed, but automatically disabled items will prevent a version from being released.
Scenarios△
Having seen the basics of what is available in Smallsite Design, here are some scenarios.
| # | Scenario | Comments |
|---|---|---|
| a | Writer | Specifically for a writer wanting to build a body of knowledge, rather than just blogging |
| b | Online help | This site is the online help for Smallsite Design, so this scenario is validated. In fact, it is because Smallsite Design needed online help that it has been properly designed to serve that purpose |
| c | Small club | Where there is one editor in charge of the site, while some key members may contribute articles, perhaps under their own subsite |
Note that Smallsite Design has not been specifically designed for uses where strict versioning is required along with prevention of alterations to the process records for that, or for ISO9000 compliance. However, just like with some popular enterprise web software packages that are also not compliant, pages can be saved as single integrated files or PDFs and stored in a records database that does satisfy such requirements. Single-file pages will work as normal except that any sequence element will probably not work.
Body of knowledge△
A body of knowledge is a coherent structured collection of information about a common subject.
A body of knowledge is built up around the subject, starting with a few core articles, then fleshing out the different aspects of the subject until there is a full enough coverage. The overriding consideration is that the information is contained in a coherent structure as that facilitates ensuring that there are no gaps in the knowledge. Only articles that value-add to the subject knowledge are included. The approach is therefore generally top-down, though organic changes in coverage can occur as the subject is explored.
The primary access method for a body of knowledge is by navigating its structure, in the same way a reference book is accessed using its table of contents. Of course, contents can still be searched, in the same way an index is used in a reference book. It is the structure that makes a body of knowledge more suitable for use in the study of a subject.
Online help△
Online help for apps needs to support context-sensitive information in multiple languages.
Smallsite Design supports context-sensitivity by allowing granular access to its content down to:
This means an app user can go to the exact information they need to help them, but can then explore its wider context by looking at the rest of the help page.
Multi-lingual support for an app can be progressively implemented because there is a fall-through hierarchy for locales. This means that help articles can start out with just the master locale and it will be served up for all the languages that the app supports. As each article has translations done for additional locales, those will be shown instead for its own locale and those in the fall-through hierarchy that have not yet been done.
If a user has viewed an article in a particular locale, following links to other articles will still use that locale, even if their content has fallen through to an ancestor locale in the hierarchy. This helps maintain the maximum reading experience for the reader in their preferred language.
Small club△
A small club wants an online presence to provide information for its members, but also as a means of getting more by describing what it does.
Small organisations will have a principal person who manages their site and its content, allowing others to contribute while the principal retains editorial control, delegation and scheduling. Subsites allow contributors to have their own mini site with its own look and feel and navigation.
Other candidates are small news outlets or publicity units, where there is the one editorial and scheduling principal. Subsites cater for specific areas of interest to serve those visitors interested in them.
Not a blog△
A blog is a day-to-day look at something of interest to the owner, without consideration of its relevance to other articles, though they may all be about a common subject.
While blogs usually list their articles by date, searching is the only practical way of using them. There is usually no way to see the overall coverage of a blog or what gaps there might be, because they are basically a diary with no other access structure. This makes blogs impractical to use as a means of building up an understanding of a subject. Each article is basically ad-hoc, self-contained and isolated from the rest.
Smallsite Design is not designed to be used as a blog. Each category could be used as such, though they would need to be manually ordered to be in reverse chronological order. However, Smallsite Design is not really designed to maintain possibly thousands of articles.
Scaling up△
While Smallsite Design has a practical upper limit of about 200+ articles, there are ways to scale that up to thousands while maintaining a degree of integration.
Scaling up can be by one or both of:
Either way, these break downs will rely upon links, and Smallsite Design provides user continuity for these by:
The principal limitations are:
- a.Sites must have the same master locale and preferably the same non-master locales.
- b.Recursive procedure calling stacks do not work across sites to prevent malicious URL insertion.
- c.Searches only work within a site.
- d.Major navigation structures, like cards or catalogs, do not allow external links, mainly due to lack of access to introductions and other information.
Because of the latter two of these, the content of each site needs to be fairly self-contained, with minimal cross-linking, so that changes in one site do not require extensive revisions to other sites. Exploiting natural boundaries in the content will facilitate this. Such boundaries also allow autonomous teams to maintain their own site, with minimal coordination required between them, other than consultation to maintain overall visual and structural consistency.
Home and navigation pages allow diagrams, which because they allow any types of links, can be used as graphical representations of the trans-site structure of the organisation or content while allowing direct access to individual components of them. A box with a different background can represent the current site's content, clearly indicating where a visitor is in the overall content structure.
Transitioning△
There are some ways of naming content that facilitates scaling a site to multiple subdomains or domains.
While scaling up may not be under consideration in the early building of a site, if the content has some natural structural consistencies, it may help with future expansion that may require it to structure the naming of categories and articles along those consistencies. This is because transitioning between single sites and multiple sites will require Redirects to ensure content will be found by those who already know the URLs, and search engines will know where the content has gone.
The Replace and Source types are suited to wildcard routing to different domains or subdomains by the starting characters of their From and To paths, where the Replace type is suited to structures that haven't changed, but Source types are for where the content has had to be restructured so only a single To path will suffice for multiple source categories and articles. While Explicit and Replace redirects automatically include any locale specified in the original URL, the Source type requires /#/ in its To path to replace the # with the current locale.
As an example of preparing for possible future scaling, a program may have several modules which have abbreviations, such as HR. If all category headings and article headlines for them start with HR: , they could all be redirected to a new dedicated subdomain for them by Replace redirects with From fields of /cat/hr- and /art/a-hr-, and To fields of https://hr.mydomain.com/cat/hr- and https://hr.mydomain.com/art/a-hr- respectively. Other article types would require their own redirects, but the overall numbers of redirects would be a lot less than having one for every category and article, making the transition significantly more manageable.
Whether to transition to separate subdomains or separate domains is dependent upon whether the content can be hosted on the same server or not. Routing across the web is usually resolved to the domain level, with subdomains on the same server. Thus if scaling is by geographical location, using servers at those locations, or at least serving them, then separate domains must be used, perhaps using the main domain name with a suffix for each. If the locations are in separate countries, the same domain name can be used with different country top-level domains.