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 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.
|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:
Files are treated more comprehensively in Smallsite Design.
While Smallsite Design does not manage file versioning by only storing the latest version, a file needs to be considered as a set of possible versions, 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 different reading directions 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 is:
This means that for direction-specific versions to work properly, the solitary directioned version must be opposite in direction to the master locale, otherwise the default would never be shown for the master locale, but might be shown as default for others.
The typical use case for using different direct 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.
Strict compliance requires that each version of an article specifies which particular version of each resource, like images, are used.
Smallsite Design is not a strictly-controlled configuration manager, 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 rendering them as PDFs or a zip of the files exported from a browser, and then storing the resultant file in the database. For governments, where the configuration records are not allowed to be modified, this process is required for many enterprise products like Atlassian's Jira and Confluence items.
Despite this, for almost all use cases used by Smallsite Design's target owners, such compliance is not required and would be unnecessarily onerous.