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.
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.
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”
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>
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.
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
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.
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
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
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
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
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
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