To main heading

Smallsite Design

Online management help

4Versioning

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.

Article 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.

The stages of an article's lifecycle in Smallsite Design are:
#StageDescription
1WIPWork in progress. Intermediate versions, each containing one editing change from the previous. Not publicly viewable
2DraftVersion for review or candidate for release. Not publicly viewable
3ReleaseApproved version that can be made 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.

To get to a release, the latest WIP is converted into a draft, then that draft is converted into a release. Technically, only the file name is changed, meaning that the release update timestamp is the timestamp of that latest WIP, not the time when made into the release.

Smallsite Design does not version everything in an article, so the three main parts of an article, and what is versioned of them, are:
#PartDescriptionVersioned
1HeadHeadline, byline, introduction and basic aside. The content of these are displayed in several places and so are kept separate from the bodyNo
2BodyMain content of the articleYes
3FilesSeparate from the article but referenced by it, so the browser proceeds to request loading of the files after the article page has been loadedNo

The main consequences of this arrangement are:

  1. a.Any changes to Head items are immediate and will be shown on the next viewing of the page on the site
  2. b.When an article has been released, any changes required for the Head items need to be done immediately
  3. c.Any version will always use the current values of the Head
  4. d.Files are updated by overwriting the current version, so there is no file version history, and the current and only version is used when referenced by a page.

Viewing WIPS and drafts

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 using the fairly neutral colours of the management theme rather than its subsite's theme. 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. To avoid confusion with the current release version, such viewing pages have a highlighted block with its status under the introduction.

The limitations applying to versions are:

  1. a.The URL is only available for 30 minutes.
  2. b.A user can only open one view at a time, across all articles.

However if a page is being viewed in this way when another is opened for viewing in another tab or window, it will remain until it times out, allowing comparisons of different edits.

File versions

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:

  1. 1.Locale – if a match to the current locale.
  2. 2.Direction – if suitable for the current locale.
  3. 3.Master locale – default.

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.

Compliance

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 always uses the current versions of its files. 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 of 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.

  • Import
  • Work list
  • Files
  • Contact   Glossary   Policies
  • Categories   Feed   Site map

  • This site doesn't store cookies or other files on your device when visiting public pages.
    External sites: Open in a new tab or window, and might store cookies or other files on your device. Visit them at your own risk.
    Powered by: Smallsite Design©Patanjali Sokaris