User needs

This section covers how to understand and meet the needs of people using your documents.

Assessing what's already in use in your organisation

You need to have good insight into your current situation so that you can decide the best way to adopt ODF.

Understanding needs

You need to understand how people inside and outside of your organisation use your documents.

You can use the information you gather from within your organisation to help you work out who uses your documents outside. You can then ask them about what they do with the information you produce.

Users within your organisation

Identify a range of users, people from different job functions and professions in your organisation. Interview them so you can understand, for example, how the needs of a statistician differ from the needs of a policy official or a worker who deals with the public on a daily basis.

There will be different types of users in your organisation. These users often work with certain file types. Here are some examples:

• The average user: the large majority of users need software to write a report or a letter, prepare an occasional spreadsheet with some simple calculations or to put together a slide pack for a presentation. These users do not require any special functionality and are therefore easier to migrate.
• The accountant: this includes all users who do anything finance related e.g. financial analysts, logistical planners, purchase controllers, etc. This type of user often has their own modified document templates and uses advanced functionality in spreadsheets.
• The developer: not only software developers, but also people in your organisation who are responsible for creating and managing templates. These users often use hybrid documents: text files, database operations and spreadsheets that are linked and where input in one type of file is created by output from another.
• The scientist: often uses special file types and advanced calculations.
• The system manager: often disregards what an ordinary user works with and works according to their own method, for example with scripts.

Users outside your organisation

You will need to make sure that you can continue sharing information with the outside world after you've migrated to ODF. Because you are more than likely moving from a vendor-specific format to an application neutral standard, it will not go unnoticed.

For many, this will be a significant relief. The switch will mean that they no longer have to cope with legacy file formats and can choose which tools they would like to use to work with documents produced by government.

Others may notice for the first time that they are hardwired to the same proprietary formats that you have worked with until now. These users will need to disentangle themselves from these proprietary formats in parallel with you.

Communicating with your team about the reasons behind the change and the benefits of moving to ODF is therefore very important. They may need to help their users and vendors to understand the change too.

Why this is important

It is very important that you have a clear understanding of your user needs so that you can support them. Do not assume that you – or a single user – reflects the needs of all users. Each department and each group of users is different.

In order to plan a successful move to ODF, you need first to understand where you are. You should spend time getting to know your users and your office environment before you get started. This will make the transition to open formats easier for the people who use your documents.

The questions to ask the users in your department

When you do user research, sit down with the people you are interviewing so you can look at their machine to see what version of what software they have and on what platforms they work. You cannot always rely on users knowing specific terminology or knowing how to find out the answer to your questions.

Ask users in your organisation the following questions:

1. To what extent do you currently use word processors, spreadsheets and presentation programmes?
2. Is there other software involved that generates or processes documents, or parts of documents, that you work with? Tell us what it is if you know.
3. On which platforms and operating systems including mobile do you currently create and view documents?
4. How straightforward or complicated are your documents?
5. Can you share some samples of your documents – some that use special formatting and some that you use often?
6. Do you use templates? If so, do you create them yourself?
7. Do you use macros? If so, do you create them yourself?
8. How frequently do you exchange documents within your organisation or with people outside? How do you exchange these documents?
9. Do you need to see or record changes in different versions of a document? If so, which platforms and operating systems do you use? Do you know of other applications used by people you work with to edit and review documents?

10.What other applications or software do you have experience of using for working with documents – for example things you might use at home?

11.Do you publish documents on the web in formats other than HTML? If so, what are they saved as (e.g. doc, odt, docx, pdf, xls, pptx, csv). What are the main reasons for publishing the content in these formats?

There are some additional questions for each of the components of an office suite that you should answering too, depending on what your users work with most (text documents, spreadsheets and presentations). Some of these questions will be for advanced users only. You should take care to phrase questions in a way that your users will understand, or to demonstrate features and ask if they use them.

Text documents

You should determine which file types are in use: make an inventory of the different versions of a file type. For example, a .doc file can be in Microsoft Word 97/2000, in Microsoft WordProcessingML or a vendor specific version of either.

Consider asking the following questions or observing your users to find the answers:

• Do you often export documents to HTML?
• Do you use special code, such as VBA, Java or Applescript? Do you use dynamically linked objects (OLE, D-BUS, DDE, ActiveX, OpenDoc etc)?
• Do you use some form of links/shortcuts in documents to refer to other documents in your system environment?
• Do you use templates for icons or graphs?
• Do you use frames, text boxes, active content controls?
• Do you use macros?
• Is the word processor often used to send e-mail attachments?
• Do you use fill-in forms?
• Do you use automatic spelling correction? Dictionaries? Or modified dictionaries?
• Do you use automatic word completion (sometimes called auto-text or AutoText)?
• Do you rely on password protection for confidentiality (including opening, changing and printing files)?
• Do you use custom fonts that need to be embedded for people outside of your organisation?
• Does your organisation aim to be inclusive, i.e. explicitly require accessibility information to be present?

Better text documents make migration easier

Many of the potential problems you might encounter do not happen if the authors of your documents follow good practice. These five simple guidelines will make your life and theirs much easier:

• Avoid direct formatting. Use character and paragraph styles. If for instance you want to use a different font size, font type, colour, letter spacing and indentation to distinguish the headings or quotes in your text from other parts, do so by selecting or creating an appropriate style for each of the different elements within your document. Apply those styles to the relevant parts. Marking something up as a header directly impacts the structure of a document. Merely making a few letters look different through direct formatting conveys no meaning about the structure and is very difficult to maintain or reuse in a consistent way.
• Use paragraph settings to determine the space above or below a line or a paragraph, instead of hard returns (with the enter key), particularly in lists.
• Use the text flow properties of a paragraph instead of manual page transitions.
• Do not use tabs or spaces to align text. Use specific tab-stops, or even better, a table.
• Avoid proprietary fonts that are bound to a platform or a (version of a) product, for which embedding in a document is not allowed. If possible, use only fonts that are generally available or that can freely be distributed and embed these in your documents. Many open source fonts are available for free from the websites of their creators, or through websites such as fontlibrary.org

Spreadsheets

Determine which file types are used in your organisation. Make a list and also specify the various file types that use the same extension. For example, a file that ends in .xls could be from versions of Microsoft Excel dating back over 25 years, or may have been created by a content management system or mobile app today.

The large variety of different file formats and the problems this causes for users is a significant part of the reason to consolidate document work flows to ODF. If you have trouble determining the answer to this question, consult a document format specialist.

Consider asking your users the following questions or observing them working to find the answers:

• Do you use a lot of input from text files to generate data for spreadsheets?
• Do you use formulae for optional parameters?
• Do you typically write complex formulae yourself, or only use existing documents or templates?
• Do you use statistical, financial or mathematical functions?
• Do you use specific features such as Quattro Pro Pivot Tables, OpenOffice.org DataPilot or Microsoft Office PivotTables?
• How large are the datasets that you handle? How is this data managed with respect to versioning, data integrity and security?
• What type of diagrams do you use? For example, bar graphs, pie charts and/or block diagrams?

Presentation documents

Make a list of the file types currently used.

Consider asking your users the following questions or observing them working to find the answers:

• How important are special effects in presentations, such as gradients in three colours, double and triple borders, dotted borders?
• Do you use corporate templates for your presentations? Who maintains them? Is there anything missing you've added yourself?
• Do you use voice-overs in presentations?
• Do you use animation in diagrams?
• Do you use mouse-over functionalities?
• Are your presentations sometimes published on the internet? Do you embed copyright information alongside photos and images?
• Does your organisation aim to be inclusive, i.e. explicitly require accessibility information to be present?

Hidden dependencies

Databases

When migrating a file format, you need to know what the current situation is to be able to choose the best course of action.

With that in mind, it is important to track down the small hidden databases inside your organisation. These are often put into place locally to solve an urgent problem. Unfortunately a quick, temporary workaround often ends up as a not so quick and increasingly permanent workaround.This is bound to cause problems later on.

Developers of these databases (often just power users) move on, or forget to inform others that they have a database running on their machine to support a specific task. In many cases there is no record of the application existing, nor is there any documentation of its functionality.

If you are making an inventory, don't forget to ask if users collect their own data and, for example, depend on small local databases to save address details, telephone numbers and email addresses. We recommend that you check the extent to which this category of database plays a role in your IT environment, and consolidate these towards a more permanent solution.

Database design requires in-depth knowledge and the interaction with text documents, presentation slides and spreadsheets can become complex. It requires the professional skills of an IT department to sustainably and securely manage within an organisation.

Are databases included in the ODF specification?

The basic information needed to connect documents to databases is specified in the Open Document Format standard version 1.3. However, the tools for working with databases is out of scope for this guidance on document formats.

Evaluating functionality according to user needs

Once you have discovered the answers to the questions, you can begin your analysis. For example, for each type of document processing programme, you can assess the functionality on a scale of 1 to 3, taking into account user needs.

Do the work step-by-step

In preparation for selecting the software that best meets your user and functional needs, you can create three files, one for each category:

• value 1
• value 2
• value 3

When you begin testing the various programmes, you can evaluate which ones will cause the most problems and which ones the least. Based on this information, you can make a step-by-step plan for the final migration.

To make early progress, you can for example choose to migrate the easiest file types in your organisation first.

Application vendors

The functionality table that you have created for your own organisation helps you to identify those documents that are created or consumed by applications from vendors you work with. For them, your migration to ODF means that they should provide adequate support for ODF to meet your needs, but beware of marketing traps.

There are a number of specific points you might want to check against the solutions providers come up with.

1. Make sure that ODF support is not just an advertising slogan, but that it is fully supported as a native format for the purpose you are seeking. {text:line-break} For instance, some products may leave out certain information when you configure them to store their output in ODF, which may mean that you still have dependencies on a second file format. Others may lose information when importing or exporting data. Some may claim that it is okay to hardwire their software with a specific office application but not support the standard. All of these are not necessary, as deep integration is perfectly possible with ODF.
2. Request complete documentation about company-specific tags in relation to XML. {text:line-break} XML allows for the insertion of any tag: even company-specific data tags that are difficult to migrate. If the meaning of the information in between the tags is not known, another application may not be able to use the information, even if the programme can interpret the reference schedule. In some cases products have used illegible, company-specific, platform-specific, non-migratable tags in applications. These practices make it complicated to read and manipulate files. You can test files by opening documents you have created in multiple applications or in a tool that will help assist you with this. Use a validator to see if the document is technically valid.
3. Ask about cross-platform operability: if you create a document in ODF on a certain platform such as Blackberry OS, Windows, Debian GNU/Linux, Fedora, FreeBSD or Mac OS X, can you read, modify and save it on another platform? Is the functionality to modify, file and request the file complete for each platform? If you depend on a single platform to manage and access documents, what will happen when that platform disappears from the market?

Be clear in your requirement for ODF

The choice of ODF as a government standard means that ODF support in applications is no longer optional. If vendors wish to sell their document products to government, they should support ODF.

Technically, it will be much simpler and cheaper for them to work consistently in one file format. ODF has a simple and elegant XML based structured. So don't be afraid to steer suppliers towards support for ODF before an existing contract ends. It may be a relatively simple change.

In order to reap the benefits of the consolidation to open file formats as quickly as possible, consider:

• insisting that your suppliers support ODF, replacing fragile application dependencies with proper standards. Don't settle for partial support, it will reduce your overall chance of success and raise costs for everyone. If a vendor is not willing to make the change, confer with other stakeholders and get it fixed. Do not let inertia get in your way, pool demand, resources and expertise.
• passing user requirements to the ODF technical committee within OASIS.
• promoting participation in technical committees of OASIS, to support and facilitate technical contributions.

Summary

To ensure a smooth migration to a new format, you must know exactly what your current situation is.

Gain an overview of what the users within your organisation expect and need.

Set out your first steps towards the migration: know which file types are used in your organisation and who uses them for which tasks.

Use the answers from your analysis to make a thorough plan to ensure a successful migration.

Being armed with a thorough analysis of your user needs and your IT environment will make the switch a relatively easy job. Migrations often fail because of the lack of adequate preparation.