As governments and organizations increasingly adopt document standards, such as ODF, for data interchange and to allow non-Microsoft products a better level-playing field, designers of documents and forms will need to alter their approaches so that users can print or display the forms on their particular without concern. Here are some rough tips, and I’d welcome more.
- The first is to treat paper pages more like HTML pages: expect that there will be some variability, rather than requiring absolute positions. This will cause challenges for machine-read forms, though.
- Don’t overfill the page. Allow space so that any fairly full paragraphs of text, as displayed in your system, might take an extra line on someone else’ system.
- Don’t overfill table cells. If you are specifying the absolute size of table cells, make sure that the largest word plus some extra can fit in the smallest cell: don’t size columns to tightly fit the word size in a paragraph.
- Use common fonts
- Use styles
- Use ems or font-size relative units where possible.
- Train your operators so that they commence bolding or italication on actual word boundaries, not the space before or after.
- Allow generous space around graphics, because some systems may make different borders.
- Consider PDF and HTML forms as well.
- View the forms on the top two applications that users will be expected to use.
Nice. Great start on what it means to interchange successfully at the level of fidelity that is required and no more.
I'm thinking that it would be great to compile "document design for collaboration and interchange." Maybe a wiki would be good for starters.
This would be great for public agencies that are basically handling discrepancies with FAQ tips rather than providing proactive guidance. Dealing with templates and accessibility could maybe be dragged along as there is enough lore.
Inspiring. Thanks.
What about "come up with a design that also works on A4 paper". I encountered that problem filing US tax returns from the UK, where all paper is A4 and not US Letter.
Orcmid: Wiki would be a good idea. I am sure Peter Sefton would have plenty of good suggestions.
Steve: A4 ++. It drives me crazy that every bloody application from US isn't smart enough to select A4 as the printer default when outside the US. Today I had to push the "continue" button at least 20 times because I had cued multiple jobs without fixing the print box. Surely printers are smart enough to tell the application that they are A4 and to give user messages before they press the OK button on the print dialog. I quite like A4: I am using it as the form factor for synthesizer modules at the moment, much to the nausea of the DIY synth community:-)
Depending, of course, on whether the form is for internal use or external use, it may be necessary to test using applications on alternate operating systems also. At the very least, Windows / Mac / Linux for any forms with outside use.
Internal use means using specified software, so that's a different kettle of fish.
W^L+: I think that internal-external distinction is too brittle.
The defaulting of the internal case to use of specified software, with maintenance of homogenous versions across an organization, is a symptom of the unavailability of standards and some reliable interchange/interoperation machinery for collaboration.
I think one wants to consider that the internal-external membrane is permeable and that heterogeneous cases are also increasingly likely in the "internal" setting.
Even if that boundary was not permeable and the internal landscape was not heterogenous, testing all documents equally rigorously is simply common-sense contingency planning. You don't want to be dependent on the precise brand and version of software you are currently using; it is in your own best interest to make sure that in case of having to switch, you will not have to spend years' worth of effort to test and convert your document base.
Aristotle: Yes, but you cannot make people who are domain experts into typesetting experts: someone who makes a document and it looks OK on their software will typically have no patience for testing it on other applications. And someone who receives a document does not know, necessarily, what the original page looked like. Consider the example of a parliamentary office, where draft legislation is passed between different members and applications: if they insist on page fidelity at document-open time, they are creating a whole lot of extra work for themselves; or, more likely, they will all standardize or settle on a single application.
dddd
Всем привет!
Хорошая погодка нынче
:)