Smallsite Design manages the versioning of articles.
Version management is useful for keeping track of content over time as it allows using old content in new articles. However, it is essential for managing the complex process of getting to the first release of an article, and from one release to the next. This is known as the article lifecycle and the type of versions represent each stage of the lifecycle.
Smallsite Design maintains versioning of articles.
In normal editing of an article in a word processing application like Word, there is no intrinsic support for identifying which version is a release, nor of hiding the intermediate versions created while getting to it, such as the drafts that are reviewed or the draft that is put up for final approval for release.
For simple articles for personal use, just repeatedly editing one version and then releasing it may be ok, but getting someone else to review it or getting it translated into several languages without managing versions may lead to a lot of confusion, especially if strict file naming conventions are not maintained. To alleviate such confusion, though at the expense of slightly more complexity, Smallsite Design maintains strict control over the process and the versions produced at each stage.
|1||WIP||Work in progress. Intermediate versions, each containing one editing change from the previous. Not publicly viewable|
|2||Draft||Version for review or candidate for release. Not publicly viewable|
|3||Release||Approved version that is available for public viewing|
Keeping track of WIP versions is very important, though often overlooked in enterprises, as most documents will spend most of their lifecycle between releases as WIPs, which if lost would be a substantial loss of intellectual property. It would typically take at least half as much time again to recreate them as it took to write them, if all that had been done was actually remembered. Smallsite Design keeps each WIP file so that any content may be retrieved at any time up until a draft is produced at which time all WIPs leading up to it are deleted.
If wanting to keep some content that will not be going into the release, that WIP can be made into a draft. Except for the draft that is made into the release, all other drafts are kept, and must be manually deleted if not wanted.
|1||Head||Headline, byline, introduction and basic aside. The content of these are displayed in several places and so are kept separate from the body||No|
|2||Body||Main content of the article||Yes|
|3||Files||Separate from the article but referenced by it, so the browser proceeds to request loading of the files after the article page has been loaded||No|
The main consequences of this arrangement are:
While WIPs and drafts are not publicly viewable, they are available for private viewing for checking.
An article displayed on the Article body page renders a page close to how it will be when released, but there are some spacing differences due to extra hidden elements for supporting the editing functionality. In the Article body and History pages, any version can be viewed in another browser tab or window. This is to allow checking for how they are exactly rendered in the browser. Their URL can be copied for use in a different browser. The only limitation is that the URL will only be valid for 30 minutes. To avoid confusion with the current release version, such viewing pages have a highlighted block with its status under the introduction.
Files are treated more comprehensively in Smallsite Design.
While Smallsite Design does not manage file versioning because it only stores the latest version, a file needs to be considered as a set of possible variants, each shown under different conditions. To elaborate, there will always be one for the master locale, which serves as the default, but a version can also be uploaded for the opposite reading direction or for each other locale. When not in the master locale, one of those other versions will be shown if it satisfies one of the conditions.
The order of preference among those versions when not in the master locale is:
To make sure that the default version is shown in the master locale, the only allowed versions other than the default are for the opposite direction and non-master locales.
The typical use case for using different direction images is for when using a full-width banner image with a leading icon and text offset towards the end. The complementary directioned image would have the icon at the opposite end of the image with text offset in the other direction. This is so the icon is always leading the text for the current locale's reading direction.
Per locale versions would be required for scenarios like documenting user procedures for software, where the sample screenshots would need text in the language and script of the viewing locale.
Strict compliance requires that each version of an article specifies which particular version of each resource, like images, are used.
Smallsite Design has version management of the bodies of articles to help with the practicalities of editing and task-assignment. It is not a strictly-controlled configuration manager for legal purposes, so it is not suitable, on its own, for ISO9000-compliant records management, because the article doesn't reference particular versions of the files it uses. That is, the versioning of files is decoupled from the versioning of articles. Smallsite Design does not manage file versioning at all, and is only holding the latest version of each file.
However, Smallsite Design articles can be held in a records-compliant database by saving them from a browser as a single file, such as .mhtmlor .htm, which keeps all content, including linked and embedded files from the same site as one file, and then storing that file in the database. That Smallsite Design doesn't allow external files ensures that the file will be a complete archive of a page.
They could also be saved as PDFs, but links and other active elements may be rendered as plain text or not shown, defeating the purpose of having a full record. For governments, where the configuration records are not allowed to be modified, this process is required for the items of many enterprise products like Atlassian's Jira and Confluence.
Articles are generally static, in that all information is visible and visibility is not controlled by checkboxes, unlike in the management pages. However, any sequence element saved as part an article to a single file will not function as its files are not saved. If wanting strict records version compliance and full working pages, avoid such elements.
Despite this, for almost all use cases used by Smallsite Design's target owners, such compliance is not required and would be unnecessarily onerous. However, that does not mean that backups should not be done, or archives not saved, as losing a site's content can very disheartening after having spent perhaps hundreds of hours building it up, let alone the financial hit taken if it is for a business. Archives are automatically created and selectively deleted according to an inbuilt schedule , but can be created on demand.