Base ODF solutions on user needs
How to find the best ODF-compliant document solution for your organisation by understanding your users' needs.
Plan your user research
To find the best possible document solution for your organisation and plan for a successful transition to using ODF, you first need to understand the needs of your users.
You’ll need to identify the:
- kinds of users reading, creating or editing documents in your organisation
- file types handled by each kind of user
- ways each kind of person uses those documents
- user needs of those people
You’ll gather this information using different methods, including internal inventories and user research. You should also get to know your users and office environment, perhaps in a more informal or less structured way.
The process of gathering and analysing this information might also reveal what document-handling practices are not working and shouldn’t be kept, and what new practices you might benefit from.
Identify user types
Most users need software to write a report or a letter, prepare an occasional spreadsheet with some simple calculations or put together a slide pack for a presentation. These users do not need any special functionality and are relatively easy to migrate.
Not every user is the average user, however. Different types of users in your organisation will often work with certain file types. You should try to find a representative group for each type of user to interview so you can better understand their individual needs.
Some examples of specific user types include:
- accountants: all users whose work relates to finance (eg financial analysts, logistical planners, purchase controllers, etc); they often have their own modified document templates and use advanced functionality in spreadsheets
- developers: not only software developers, but also those creating and managing templates; they often use hybrid documents such as text files, database operations and spreadsheets that are linked and where input in one type of file is created by output from another
- scientists: they often use special file types and advanced calculations
- system managers: they often disregard what ordinary users work with and work according to their own methods (eg with scripts)
Interviews with these users generate your user research, which you’ll use to determine:
- which file types are used in your organisation
- who uses them and for what tasks
When you conduct user research be sure you can observe what sort of software your interview subjects are using and on what platforms. You cannot always rely on users knowing specific terminology or knowing the answers to more technical questions.
Questions for users: text documents, spreadsheets, presentations, databases
In the interviews, ask your users the following questions:
- To what extent do you currently use word processors, spreadsheets and presentation programmes?
- Do you work with other software that generates or processes documents, or parts of documents? Tell us what it is, if you know.
- On which platforms and operating systems (including mobile) do you currently create documents? And on which do you view documents?
- How straightforward or complicated are your documents?
- Can you share some samples of your documents - some that use special formatting, and some that you use often?
- Do you use templates? If so, do you create them yourself? Can we take a look, or could you send them over?
- Do you use macros? If so, do you create them yourself?
- How frequently do you exchange documents, within your organisation or with people outside? How do you exchange these documents?
- 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?
- What other applications or software do you have experience of using for working with documents - for example things you might use at home?
- Do you publish documents on the web in formats other than HTML? If so, what are they saved as (eg doc, odt, docx, pdf, xls, ppt, csv)? What are the main reasons for publishing the content in these formats?
- Have you experienced migration between different formats before, for example in a product migration from WordPerfect Office to Microsoft Office or Lotus Symphony (or vice versa)? What was your experience?
- What security and confidentiality functionality do you use on your documents?
There may be additional questions for each of the components of an office suite, depending on what document types your users work with most (text documents, spreadsheets and presentations).
Some of these questions will be for advanced users only. You should phrase questions in a way that your users will understand, or demonstrate features and ask if they use them.
You should determine which text file types are in use. Make an inventory of the different versions of every file type. For example, a .doc file can be in Microsoft Word 97/2000, in Microsoft WordProcessingML or in another supplier’s 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 or 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? For what purpose?
- Do you often use the word processor to send email attachments?
- Do you use fill-in forms? For what purpose?
- Do you use automatic spelling correction, dictionaries or modified dictionaries?
- Do you use automatic word completion (sometimes called 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?
- Do you add accessibility information to the documents you create (eg written descriptions of images)?
Determine which spreadsheet 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 a single open standard. 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 formulas for optional parameters?
- Do you typically write complex formulas 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, confidentiality and security?
- What type of diagrams do you use? For example, bar graphs, pie charts or block diagrams?
Make a list of the presentation file types currently used in your organisation.
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 3 colours, double and triple borders, dotted borders?
- Do you use corporate templates for your presentations? How are these maintained? Was 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 or provenance information alongside photos and images?
- Does your organisation aim to be inclusive, ie explicitly require accessibility information to be present?
You’ll need 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 being a time-consuming and increasingly permanent one that’s likely to cause problems later on.
Developers of these databases (often just advanced users) move on, or forget to inform others that they have a task-specific database running on their machine. In many cases there is no record of the application existing, nor any documentation of its functionality.
If you’re making an inventory, do not 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. Check the extent to which this category of database plays a role in your IT environment, and consolidate these towards a more permanent solution.
Interaction between a database and text documents, presentation slides and spreadsheets can become complex. Designing and then managing databases securely and sustainably within an organisation requires the in-depth knowledge and professional skills of an IT department.
The basic information needed to connect documents to databases is specified in the Open Document Format standard version 1.2. However, the tools for working with databases is out of scope for this guidance on document formats.
Select a solution based on user needs
Make a list of functionalities and requirements, taking into account the user needs.
Try to distinguish between how your users currently work, and how your organisation would like them to work. For example, they may still make use of macros even if this goes against best practice in your organisation. In this case you would need to factor in developing alternatives for their use.
Create a shortlist
Create a shortlist of applications you’re considering. You can also send out an informal request for proposals, or publish a list of the functionalities your organisation requires and request feedback.
Assess the functionality of each of these applications.
|Must||Describes functionality or requirements that must be included.|
|Should||Represents high-priority functionality that should be included if it is possible. People in your organisation would experience problems if this functionality did not work, but could operate if there’s a work-around solution.|
|Could||Describes functionality that’s considered desirable but not necessary. To be included if time and resources permit.|
|Will not||Represents irrelevant functionality, not deemed important enough to justify cost or effort.|
|Shall not||Represents functionality or characteristics that are explicitly not appropriate and would disqualify certain products or services.|
Your organisation needs to cover all the functionality marked as a ‘must’, and as much as possible of the functionality marked as ‘should’ and ‘could’, but it is not essential to combine all of these in a single solution.
The classification ‘shall not’ will act as a blacklist. If for example there is a hard requirement for security and confidentiality of data, and a certain solution does not satisfy this requirement, it is not suitable.
For each of the 3 functionality groups ‘must’, ‘should’ and ‘could’, create a table of potential solutions with 5 columns:
- functionality (concise description of functionality)
- name (the name of the product, service or solution)
- cost (eg estimated total deployment cost of this solution for your organisation)
- platforms (supported platforms)
For each table, add a row for each of the solutions that fulfills the criteria and fill it out. Make notes of particularly useful, unique features, and important caveats that products have. If you’re uncertain, contact product suppliers or companies that offer support for that product with your question.
Aim for a baseline service
An application or family of applications does not need to address every user need. It’s advisable to establish a ‘baseline service’ for all users, which could mean:
- one productivity solution on each desktop
- one productivity solution on each desktop plus access to a flexible web-based solution that’s accessible on other platforms
When user needs arise that are not covered by this baseline service, it can be optimised or added to rather than replaced. Your organisation can ensure adequate support for the baseline service, while allowing power users to work with more advanced solutions.
Identify suitable combinations
Based on the table of potential solutions, identify the top 3 combination of solutions that would be the most suitable for setting your baseline. You’ll need to test these solutions in more detail, to find out if the requirements of your users are indeed met. Do not forget to check if a product is on the ‘shall not’ blacklist.
Match each solution with the requirements list of the individual users. If you can, ask the actual users who you worked with earlier to help you assess which solutions satisfy their requirements.
If you’ve selected open source solutions that you’ll be downloading, with no cost attached, you can directly continue with planning your migration and procuring the services necessary to do so.
If you’ve selected proprietary, paid-for solutions, you’ll need to follow a procurement path to access the software. There is separate guidance on procurement that contains more detail for each of these scenarios.
Users outside your organisation
You’ll need to make sure you can continue sharing information with people outside your organisation after you’ve moved to ODF. Because you’re more than likely moving from a vendor-specific format to a format that can be used in many applications, it will not go unnoticed.
Some external users will be working with the vendor-specific formats that most of government has worked with until now. However, there are several modern office productivity tools that work with ODF and are free to access or download.
In many cases users’ needs will be better served by providing documents in HTML, which can be viewed on almost every modern device and platform that has a web browser installed. This is often simpler and more cost-effective than installing new software and is more accessible.
Make sure your team is informed about the reasons behind moving to ODF and what its benefits are, as they’re likely to get direct questions about it from outside users.