NoteThis article is applicable to Appspace Intranet version 4.6.0 onwards.
From Appspace Intranet version 4.6.0 onwards, all sites will be created as Draft, and will be visible only to Site Owners and Global Admins until an owner decides the site is ready to be published. This feature ensures that users have a safe space to prepare content before making it available to their entire organization.
Create Draft Site
Perform the following steps to create a draft site. These steps are similar to versions before 4.6.0.
- Log in to your Appspace Intranet account.
- Click the User Menu and select Editorial Settings.
- On the left bar, click Org Structure. Under the Org Structure, click the > Expand arrow to expand the site or sub-site. Move your mouse over the site you wish to create a draft site under and click on the (+) icon (Create child site).
- After the site is created, the user will see a label next to the name indicating that the site is still in Draft.
After the creation itself is finished, the name and label of the Site will become darker, hence indicating that the process is finished.
After the creation process has finished the Draft Site is now ready to be edited by the Site Owners, being easily accessible by them through the user menu at the very top positions of the list.
Edit Draft Site
Entering a Draft Site’s settings page will now display a much cleaner UI, as some nice improvements have been introduced.
The header is now full width, the back button has been normalized to be coherent with other areas of the product, a nice Draft label was added near the ‘Edit site’ literal and we now have 3 available actions:
- Preview: takes the user to a page in which they can see how the Draft Site will look with the current content;
- Save: saves the edited content;
- Publish triggers the publishing process to make the site accessible for the entire organization;
Starting by the Preview button, the user will be redirected to a similar view as we do have in published Sites, but with a small banner indicating that the Site is still on draft.
Clicking on the “Edit site” option in the banner will take the user back to the corresponding Site Settings;
There are two specificities to bear in mind when previewing a Draft Site:
-
The ‘Related Sites’ widget will show directly connected levels with other Draft Sites, but they will be hidden once the site is published to avoid polluting end-users.
-
Users now have the option to associate Draft Pages to a Draft Site through the Site Settings, which will be visible as such:
To achieve this result we expanded the search results retrieved in the ‘Pages’ tab of the Site Settings to return Draft pages (identified accordingly) when we’re editing a Draft Site.
If the site is then published, the connection with the Page will be hidden until the page itself is also published.
The Save behavior is now cleaner and triggers a pop-up message to give feedback to the user about successful/unsuccessful changes, substituting the current behavior of redirecting the user to the preview of the page.
Publish Draft Site
Triggering the Publish option will trigger a modal alerting the user that the change can’t be reverted. This means that users won’t be able to unpublish a published site.
If indeed the user chooses to continue, after some seconds he/she will be redirected to the public view mode of the site, which it will be noticeable since the preview banner will have disappeared.
From this point onwards, our Site is available for our entire organization and editing will happen with some simplified options in the header.
We will just be showing a single ‘Update’ button to save changes and take the user to the public view mode of the Site.
Publish Nested Draft Site
Since sites can be nested inside each other, users will quickly reach a point in which they publish a Site nested inside a Draft one, which is something that should be closely followed by the platform Admins.
Since we don’t want to expose end users to the complexity of Draft Sites, the Org Structure tab in the Editorial Settings will show all existing published and draft sites, but we will be hiding it in the ‘Our Organization’ page.
To achieve this, when we publish a child site of a draft one, the draft one will be shown as a node in the ‘Our organization’ page.
Supporting this with some examples: a ‘New Departments’ Site is being prepared, but it just so happens that the ‘Employee Happiness’ team got ready first and they published it before waiting for the parent Site to also be published.
In this case, through the Editorial Settings the full structure will be shown:
But public users will see the ‘New Departments’ draft Site as a standard node in the ‘Our Organization’ page:
For performance sake, bear in mind that the ‘Our Organization’ tree isn’t indeterminably expandable. So if the algorithm reaches a level in which a certain site only has child Draft sites (or no children at all), it won’t paint anything else in that branch of the tree. Even if there’re published grandchildren underneath it.
This is where the Global Admin role comes into place in its responsibility to keep the Editorial Settings clean if they want to give the site visibility in this tree. Nonetheless, the Site will still be searchable and visible to everyone in the rest of the product.