Good visual communication is essential, yet graphics are often an afterthought in DITA implementations. We need a new approach to make them work well over an increasing range of screen sizes, devices, and contexts. Graphics illustrate relationships, demonstrate subtle concepts, and build emotional connections with brands. But they have to look clear and attractive over many screen sizes and software tools. As our image libraries grow, we can't keep manually tweaking different versions for different outputs. Image processing tools are smart enough to handle this automatically; we just need to set up the rules. But the key to success is information architecture: the same needs analysis, planning, and content type definitions that we'd apply to any structured content solution.

1. Better DITA Graphics
for a multi-screen world
Joe Pairman

2. Implemented DITA at HTC
Jointly with SDL, designed
image rendition plugin for
SDL LiveContent Architect
Designed mobile content
delivery platform
Now consulting at Mekon

3. I’ll provide a complete recipe for
defining an automated graphics
solution…

4. I’ll provide a complete recipe for
defining an automated graphics
solution…
!
!
…but first some background on
why we really need to do this.

5. Visual communication has always
been important in tech comm

6. Graphics illustrate relationships,
demonstrate subtle concepts
“territorial water
claims of 3nm
and 12 nm”
“continuous
control over
valve lift”
“the icon that
looks like two
arrows merging”

7. Graphics illustrate relationships,
demonstrate subtle concepts
“territorial water
claims of 3nm
and 12 nm”
“continuous
control over
valve lift”
“the icon that
looks like two
arrows merging”

8. We're much more visual
these days

9. Photo
sharing has
exploded

10. Even sober
statistics
need an
over-the-top
font and
background

11. Our end users clamor for more
screenshots and videos

12. Strong branding demands
high-quality images

13. We're more web-y too

14. Primary
place we
look for
content is
on the web

15. Graphics
may boost
visits from
organic
search

16. And, of
course,
“mobile”

17. Not tame little
“mobile” tasks
but the
whole thing

18. So change the navigation,
but don't leave things out!

19. Responsive design is mainstream

20. It's challenging to
cater for multiple
screens

21. Display
size
Images should fit
containers, but …

22. Display
size
…not all images
should use the full
container width

23. Display
size
…not all images
should use the full
container width

24. High resolution displays
- low res images are blurry if scaled up
- high res images need extra bandwidth & storage

25. High resolution displays
- low res images are blurry if scaled up
- high res images need extra bandwidth & storage
- we need appropriate image versions per device

26. High resolution displays
- low res images are blurry if scaled up
- high res images need extra bandwidth & storage
- we need appropriate image versions per device
<img src="testimage.png"
srcset=“testimage@2x.png 2x,
testimage@3x.png 3x"
width="500px" alt=“Test image">

27. “Art direction”
- key visual info should be clear no matter the image
display size

28. “Art direction”
- key visual info should be clear no matter the image
display size
<picture>
<source media="(min-width: 45em)" srcset="large.jpg">
<source media="(min-width: 32em)" srcset="med.jpg">
<img src="small.jpg" alt=“Hikers at Rattlesnake
Ridge.">
</picture>

29. How do DITA
users cater for
multiple screens?

30. Graphics survey: less than half
cater for multiple screen sizes

31. More than
half of
survey
respondents
feel it's
difficult

32. Graphics production seen as
inefficient and expensive
Cost and effort of localizing graphics, especially
screenshots, is a major reason they are discouraged
here, though some teams use them.
For html output in DITA we have to convert to a
viewable format. We are still determining the best
way to do this for our html output (source in what
we upload vs converting while publishing to html).
We conditionalize out most graphics
for HTML output.

33. We tweak
manually

34. We tweak
manually

35. With graphics,
we’re still stuck in
DTP-land!

36. It doesn't scale across different
outputs and screen sizes
2 minutes tweaking ×
50 images per publication ×
3 outputs ×
10 languages =
50 hours

37. Nearly half
would use
more
graphics if it
were easier

38. Just as with our textual content,
our graphics need automation

39. Using any tool with a command-line
interface…

40. We can
scale or
crop

41. …even preserving important
information automatically

43. We can
automate
vector
graphics
conversions
too

44. Over half of
respondents
use SVG

45. Some felt it could be easier to
work with SVG...
It would be great to use a vector graphic and have it
automatically size depending on the output. Or have
vector graphics rasterize at build time.

46. ... in fact, SVG resizing can be
automated fairly easily

47. And it’s easy to rasterize vector
graphics automatically

48. ... we could automate the
production of SVGs …

49. … for example, to highlight
important info
These Wikipedia and Wikimedia Commons images are from the user Chris 73 and are freely available at //commons.wikimedia.org/wiki/File:Map_of_Sealand.png under the creative commons cc-by-sa 3.0 license.

50. …or to make translation easier

51. We could even have dynamically
regenerating images

52. We could even have dynamically
regenerating images

53. … which is all fine, but how do
your image editing tools know
what transformation to do and
what parameters to use?

54. IA to the rescue!

55. What did
we do to
overcome
DTP?

56. We tagged textual content
semantically

57. We
modularized
and
chunked
topics

58. We defined pieces of
information for the role they
played (not how they should
look in any particular situation)

59. We can do this with graphics.
They can be grouped by role…
Icons Simple screenshots Diagrams

60. …and processed automatically
based on rules you define
If the source
graphic is a:
And the output
format is:
Do this:
Screenshot from
a tablet with
display of 768 ×
1024 pixels
PDF Set nominal PPI so that 768 pixels
will measure 1.8 inches (i.e. 427 PPI)
Icon intended for
use inline
Web Create a “regular” version 25px high
and a 2× “retina” version 50px high,
naming them so responsive image
delivery solution can use them

61. Defining the rules.

62. 1. Audit graphics & define the
roles they play
2. Define content types and
output requirements
3. Research transformations
4. Define naming scheme

63. Auditing graphics is an excellent
chance to apply minimalism

64. Categorize remaining images by
the visual role they play
Examples:
Role Description
Inline icon Needs to fit well into inline text.
Definition table
icon
Larger than inline icons, as the extra space in a table
allows for more detail to be shown.
Screenshot Can take up to the whole column / container width,
but care needed so it doesn’t look out of proportion
with the text.
System diagram Most of these have significant detail. Care needed to
preserve this detail on a small screen.

65. A role is not the same as a
graphics format!
We can’t treat these PNGs the same way
Icons Simple screenshots

66. 1. Audit graphics & define the
roles they play
2. Define content types and
output requirements
3. Research transformations
4. Define naming scheme

67. Icons need
to fit
comfortably
in body text
or tables

68. Keep proportion across whole
docset / repository?

69. Resize or highlight diagrams?

70. Source image Output type and corresponding renditions
PDF Web (lo-res) Web (hi-res)
Inline icon PNG Control display height. Inline icons should be as large as possible without
overlapping or overly pushing out surrounding lines of text. Table icons
should be bigger but still a set height. Needs further research as to exact
sizes. Definition
table icon
Smartphone
screenshot
Control display size.
Size should be based
on 1.8 inches wide for
an uncropped, portrait
aspect screenshot.
Preserve fidelity of
original image.
Control display size.
Size should be based on
280 pixels wide for an
uncropped, portrait
aspect screenshot.
!(
Cropped images
should be
proportionately
smaller.)
Control display size.
Size should be based on
560 pixels wide for an
uncropped, portrait
aspect screenshot.
!(
Cropped images
should be
proportionately
smaller.)
Tablet
screenshot
Diagram SVG Use full container width. In a later phase, consider whether highlighting
can be scripted in illustration tool.

71. 1. Audit graphics & define the
roles they play
2. Define content types and
output requirements
3. Research transformations
4. Define naming scheme

72. Research the commands &
parameters you’ll use

73. Source image Output type and corresponding renditions
PDF Web (lo-res) Web (hi-res)
Inline icon PNG 1. Use ImageMagick to get
height
identify -format %h
!input_file.png
2. Divide height by specified
!display size to get required PPI
3. Set PPI
convert -units PixelsPerInch
-density required_ppi
input_file.png
output_file.png
Use ImageMagick to set height as specified per content
type
Definition convert -resize required_height input_file.png
table icon
Smartphone
screenshot
Use ImageMagick to set PPI as
specified per content type
convert -units
PixelsPerInch -density
required_ppi input_file.png
output_file.png
1. Use ImageMagick to get current width
!identify -format %w input_file.png
2. Calculate what width would be after required
percentage resize specified per content type. If it would
be over specified max width, then set max width as the
r!equired width
3. Use ImageMagick to resize and convert to Q90 JPG
convert -resize required_width -quality 90
-flatten input_file.png output_file.jpg
Tablet
screenshot
Diagram SVG [Set width with custom XSL] Use Batik rasterizer to convert image to Q90 JPG and
resize to a fixed specified width
java -jar
"%ProgramFiles%batik-1.7batik-rasterizer.jar"
-m image/jpg -bg background_color -w
required_width -q 0.9 input_file.svg

74. 1. Audit graphics & define the
roles they play
2. Define content types and
output requirements
3. Research transformations
4. Define naming scheme

75. Filename suffixes are simple and
reliable
Source image Image suffix
Inline icon -inlineicon
Definition table icon -tableicon
Smartphone screenshot -640x1136screenshot
Tablet screenshot -768x1024screenshot
Diagram -drawing

76. What next?

77. 1. Audit graphics & define the
roles they play
2. Define content types and
output requirements
3. Research transformations
4. Define naming scheme
5. Decide technical architecture
6. Test everything

78. Two main approaches:
1. Store the source image;
render output images when
publishing
2. Render images on import to
CCMS

79. Approach 1: Store the source
image; render output images
when publishing
Render
graphics
Import
graphics
Store in
CMS
Publish
Render
graphics
Render
graphics
DITA
processing
DITA
processing
DITA
processing

80. Approach 1: Store the source
image; render output images
when publishing
• Pros: more flexible
• Cons: slower publishing
(though some smart work on
caching could alleviate this)

81. Approach 2: Render images on
import to CCMS (storing source
image too)
Render
graphics
Store in
CMS
Import
graphics
DITA
processing
DITA
processing
DITA
processing
Publish

82. Approach 2: Render images on
import to CCMS (importing
source image too)
• Pros: publishing performance
better, can automatically
create a preview resolution
• Cons: less flexible, can be
tricky to batch reconvert

83. Use a config
file format
— there
will be
tweaks!

84. 1. Audit graphics & define the
roles they play
2. Define content types and
output requirements
3. Research transformations
4. Define naming scheme
5. Decide technical architecture
6. Test everything

85. Results

86. By applying IA techniques to
graphics transformations…

87. …we get a pushbutton solution
that’s vastly more efficient.
2 minutes tweaking ×
50 images per publication ×
3 outputs ×
10 languages =
50 hours

88. As with move from DTP to
structured authoring, content
developers may feel less control
9QVPQVYGCMKPI!

89. But automation creates space,
time for real design work

90. …and gives
customers
all the info
they need,
where they
need it.

91. Questions? Thoughts?
joe.pairman@mekon.com

92. Acknowledgments
Slide 11: Video by Mark Poston.
http://goo.gl/HUvvwk
Slide 18: Graphic by Strangeloop.
http://goo.gl/uh2mnE
Slides 41-42, 51: Research by Yu-Shuen Wang
and others. http://goo.gl/kbkVw0
Slide 62: Presentation by Marie-Louise
Flacke at DITA Europe 2011.
http://goo.gl/ZLSolk