Smallsite Design is for those solo operators and small clubs or publicity units who want to manage their own site. But, it can also scale to handle multi-lingual online help.
Specifically, Smallsite Design is designed for:
Smallsite Design is for writers who want to build a quality body of knowledge, rather than a blog of daily writings that disappear into an archive almost immediately.
Smallsite Design supports writers by:
- a.Using a structured editor for articles, so that inadvertent keystrokes do not break an article's structure.
- b.Managing the whole article life-cycle, including works-in-progress and drafts.
- c.Supporting private viewing of drafts by selected reviewers.
- d.Providing specialised structured article types for glossaries, procedures, tests, policies and contact.
- e.Providing categories, by which related articles are grouped, and automatically providing list pages for each.
- f.Supporting multiple subsites, each with their own home page, navigation and Atom feed.
Note that, because of other design decisions, the practical upper limit for the number of pages for each Smallsite Design setup is in the hundreds, which is the expected upper limit for the target user base. If your output is expected to be prodigious, you could run a main Smallsite Design setup on a domain, with another on each of several subdomains, each covering a subarea of interest.
Publicity units for small clubs or councils may have only one editor, but a few part-time or volunteer writers servicing areas of interest.
Smallsite Design supports such operations by allowing:
Here, the emphasis is on small, as larger operations need collaboration and sophisticated workflow management, subscriptions and other facilities.
Providing multi-lingual online help is another use for which the simplicty of Smallsite Design can make implementation quite straightforward.
Given the small-site focus of Smallsite Design, massive online help may seem a bit odd to be catering for. The answer is simple, Smallsite Design needs its own online help, so why not allow the product to do that as well, by using an architecture that uses the product to its best advantage.
In reality, online help in Smallsite Design is just a particular scenario for using its multilingual facilities. Each article includes the text of all supported languages, but only the text for the current locale's language is displayed.
Note that rather than plain languages per se, Smallsite Design uses locales, which are a language identifier, followed by optional script, such as for Latin or Cyrillic, and location identifiers. This allows for locality-specific variations in spelling, grammar, time presentation and examples, such as for US and UK English. These have a standard format, like ar-ye for arabic in Yemen, en-us for English in the United States, or zh-hant-hk for traditional Chinese as used in Hong Kong.
The basic process for using Smallsite Design for online help is:
- 1.A user of your program clicks on a help link, with a target URL in the form of:
- 2.If there is text for that locale in the article, it is used, otherwise it uses the text for the designated fallthrough for that locale.
- 3.The process continues until a locale in the chain has the text, ending at the site root for any locale without a fallthrough.
- 4.If there is no such topic, a list of the available subsites or categories is shown.
Fallthough occurs on an article-by-article basis, but also on all text blocks within an article. For example, most of an article's English could be for en-001, which is for the world, with any specific English versions falling through to it, but individual paragraphs or other blocks, for say en-gb, where there are variant spellings, can have their own explicit text.
All the links on a substitute version's page still point to the originally requested locale for other pages.
The advantages are of this simple arrangement are:
Online help is where the simplicity of the Smallsite Design can achieve enough scale to provide a big solution. However, for online help for really large programs, which may require thousands of topics, perhaps use a subdomain per program module, as per
While allowing ads on a site is the current way many choose to make money from their site, there are several downsides to that approach.
Ads tend to:
- a.Be visually disruptive to readers of your article.
- b.Persuade your readers to abandon your site.
- c.Open all your visitors to being tracked across the web.
- d.Result in the quality of articles tending towards merely being minimally-written click-bait to attract visitors to look at ads.
- e.Subvert your brand.
Conversely, by not allowing embedded ads, and especially for those who value what they write, Smallsite Design is:
Preventing tracking is also why all media must be hosted on the site, and no third-party inserts are allowed. If you want to have a discussion thread for an article, you can bidirectionaly link to your own associated Discus or LinkedIn post page.