Converting policy documents written in Word to HTML – Example

In recent posts, we’ve been describing the different ways to publish policy and procedure documents online. Often, organisations want to write their content in Microsoft Word, as staff are familiar with the application. However, they also want a very nice, and usable, online version.

Here’s an example of a direct conversion from Word to HTML.

Before – Example Mobile Phone Policy IT-0022-v2

policy-example-before-screenshot

After – Mobile phone policy – written in Word  and converted to HTML

policy-example-after-screenshot

In this example, we have not amended the source content before conversion, nor the default template. We just imported the document and pressed the Build button.

The document has been broken down into a series of web pages, with a responsive web layout. This means the pages can be easily read on a mobile phone.

The writers would make any changes to the policy by amending the Word document. You’d then run the conversion again, and upload the revised web pages.

Pre- and Post- Brexit procedures examples

Below are two proof of concept examples of a policy document. In these examples, the selling old mobile phones topic contains a filter for pre- and post- Brexit information. Users can use the filter option to switch between both versions.

The benefit of doing this is because the reader doesn’t get overwhelmed with information, and the writer can manage the both sets of information in a single topic.

Mobile phone policy – version 1

This example has tabs on the left hand navigation panel.

policy topic

The funnel icon tab enables you to exclude content. In this example, you can exclude pre- and post- Brexit information on the selling old mobile phones topic.

policy topic

policy topic

The A-Z folder icon tab enables departments, budget holders and line managers to see which topics are relevant to them.

policy topic

Mobile phone policy – version 2 

In this example, you can exclude pre- and post- Brexit information on the selling old mobile phones topic by using the drop down menu at the top of the topic.

policy topic

policy topic

It also contains a job role tab that enables departments, budget holders and line managers to see which topics are relevant to them.

job role topic

You can click on the menu icon to display the navigation window.

Brexit and the impact on organisational policies and procedures

With the triggering of Article 50, the United Kingdom is likely to be out of the single market in two years time. It will be able to set its own regulations within the United Kingdom, but will almost certainly have to follow EU regulations when trading with EU27 countries.

This means organisations will have to manage two sets of compliance rules, and possibly two sets of policies and procedures, which will be similar in many areas.

One approach is to have two documents, cutting and pasting between the two. This can be time-consuming, and with this approach it is easy for mistakes to creep in.

Another way is to have one document with different sections marked up to identify which territory’s rules they relate to. This is known as conditional text. You create “conditional build tags” to include or exclude content from output, and then assign those tags to topics or parts of topics. For example, when you publish, you set the conditions to “United Kingdom” for the UK-only guide, and it will only contain the United Kingdom rules.

conditional text

conditional text publishing

You can also create output that your users can easily filter based on parameters that you define using conditional text. For example, you can create a filter that allows your users to filter the output by UK or EU27 rules.

Filter content by country

This approach means your writers can work from a single source – no more cutting and pasting!

The T-Bot: A new Help model from Microsoft

This month, Microsoft has added Microsoft Teams to Office 365. It’s a instant messaging collaboration tool, similar to Slack. Teams contains the T-Bot, which provides help and assistance to users.

T-Bot main screen

Users can watch videos:

T-Bot Help videos

They can read online Help:

T-Bot online Help

They can read an FAQ:

T-Bot FAQ

They can ask the T-Bot a question and receive an answer. The T-Bot initially provides the same answers as the FAQ. If it doesn’t know the answer, it will suggest some articles from the Help:

:T-Bot Question and Answer

Do you think this way of helping users is good? Share your thoughts, using the comments form below.

Getting users to read the Help rather than call support

We spotted an interesting statement by the “Father of Behaviour Design”, BJ Fogg:

“For somebody to do something – whether it’s buying a car, checking an email, or doing 20 press-ups – three things must happen at once.

The person must want to do it, they must be able to, and they must be prompted to do it.

A trigger – the prompt for the action – is effective only when the person is highly motivated, or the task is very easy. If the task is hard, people end up frustrated; if they’re not motivated, they get annoyed.”

See Ian Leslie’s article “The scientists who make apps addictive“.

If we want users to read Help text instead of calling the support line, then we maybe we need to meet those three criteria.

We can assume the user is motivated to fix their problem.

We can write instructions that are clear enough to make them able to solve the problem.

Where some applications fall down is they don’t prompt the user to read the online Help. The link to the Help text is often tucked away in the right hand corner of the screen.

Instead, we could put some of the Help text into the User Interface or the dialog screens,  and we could prompt the user to follow a link to more information. Doing this could get users to read the online Help rather than call support.

Using Hemingway on our website

Last week, we used the Hemingway app to highlight any unclear pages on our main website. The app highlighted four pages where we’d used the passive voice or very long sentences.

The first inclination was to think our readers are cleverer, our content is more technical, it’s not possible to rewrite those parts. We found, of course, we could rewrite them. We decided to write them in the same way we’d write user documentation. We found those passages were much clearer, as a result. A lesson learnt.