better dita graphics for a multi-screen world
DESCRIPTION
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.TRANSCRIPT
Better DITA Graphicsfor a multi-screen world
Joe Pairman
Implemented DITA at HTC
Jointly with SDL, designed image rendition plugin for SDL LiveContent Architect
Designed mobile content delivery platform
Now consulting at Mekon
I’ll provide a complete recipe for defining an automated graphics solution…
I’ll provide a complete recipe for defining an automated graphics solution… !
!
…but first some background on why we really need to do this.
Visual communication has always been important in tech comm
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”
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”
We're much more visual these days
Photo sharing has
exploded
Even sober statistics need an
over-the-top font and background
Our end users clamor for more screenshots and videos
Strong branding demands high-quality images
We're more web-y too
Primary place we look for
content is on the web
Graphics may boost visits from
organic search
And, of course,
“mobile”
Not tame little “mobile” tasks but the whole thing
So change the navigation, but don't leave things out!
Responsive design is mainstream
It's challenging to cater for multiple screens
Display size
Images should fit containers, but …
Display size
…not all images should use the full
container width
Display size
…not all images should use the full
container width
High resolution displays - low res images are blurry if scaled up - high res images need extra bandwidth & storage
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
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=“[email protected] 2x, [email protected] 3x" width="500px" alt=“Test image">
“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>
“Art direction” - key visual info should be clear no matter the image display size
How do DITA users cater for multiple screens?
Graphics survey: less than half cater for multiple screen sizes
More than half of survey
respondents feel it's difficult
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.
We tweak manually
We tweak manually
With graphics, we’re still stuck in DTP-land!
It doesn't scale across different outputs and screen sizes
2 minutes tweaking × 50 images per publication × 3 outputs × 10 languages =
50 hours
Nearly half would use
more graphics if it were easier
Just as with our textual content, our graphics need automation
Using any tool with a command-line interface…
We can scale or
crop
…even preserving important information automatically
We can automate
vector graphics
conversions too
Over half of respondents
use SVG
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.
... in fact, SVG resizing can be automated fairly easily
And it’s easy to rasterize vector graphics automatically
... we could automate the production of SVGs …
… 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.
…or to make translation easier
We could even have dynamically regenerating images
We could even have dynamically regenerating images
Fig. 9. From top to bottom are the metro maps of Stockholm, Mexico City and Sydney. (left) The geographic layouts. (middle and right) Thefocus+context results are automatically determined using our system.
6 CONCLUSIONS AND FUTURE WORKS
We have introduced the concept of focus+context layout for metromap visualization. This technique is particularly useful when visu-alizing a complicated map on a mobile device because unnecessarytransportation lines are abstracted. By entering the start and destina-tion stations, our system determines the user-oriented layout fully au-tomatically. The best route to the destination of a visitor is magnified.The names of focal stations are labeled. In addition to highlighting
the focal route, the contextual parts of the map are retained to per-sist within the screen to show the basic geographic information. Ourmethod preserves the metro map criteria when relocating stations suchthat the visual artifacts are minimized. The experimental results verifyour focus+context visualization technique.
We have successfully tested our program on a desktop PC. Giventhat the algorithm is designed for displaying maps on a small area, wethus plan to implement our method on a mobile device and raise thetechnique to a product-level system.
… which is all fine, but how do your image editing tools know what transformation to do and what parameters to use?
IA to the rescue!
What did we do to
overcome DTP?
We tagged textual content semantically
We modularized
and chunked
topics
We defined pieces of information for the role they played (not how they should look in any particular situation)
Icons Simple screenshots Diagrams
We can do this with graphics. They can be grouped by role…
…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
Defining the rules.
1. Audit graphics & define the roles they play
2. Define content types and output requirements
3. Research transformations 4. Define naming scheme
Auditing graphics is an excellent chance to apply minimalism
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.
A role is not the same as a graphics format!
Icons Simple screenshots
We can’t treat these PNGs the same way
1. Audit graphics & define the roles they play
2. Define content types and output requirements
3. Research transformations 4. Define naming scheme
Icons need to fit
comfortably in body text
or tables
Keep proportion across whole docset / repository?
Resize or highlight diagrams?
Source image Output type and corresponding renditionsPDF 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.
1. Audit graphics & define the roles they play
2. Define content types and output requirements
3. Research transformations 4. Define naming scheme
Research the commands & parameters you’ll use
Source image Output type and corresponding renditionsPDF 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 convert -resize required_height input_file.pngDefinition
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 required 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.7\batik-rasterizer.jar" -m image/jpg -bg background_color -w required_width -q 0.9 input_file.svg
1. Audit graphics & define the roles they play
2. Define content types and output requirements
3. Research transformations 4. Define naming scheme
Source image Image suffix
Inline icon -inlineicon
Definition table icon -tableicon
Smartphone screenshot -640x1136screenshot
Tablet screenshot -768x1024screenshot
Diagram -drawing
Filename suffixes are simple and reliable
What next?
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
Two main approaches: 1. Store the source image;
render output images when publishing
2. Render images on import to CCMS
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
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)
Render graphics
Store in CMS
Import graphics
DITA processing
DITA processing
DITA processing
Publish
Approach 2: Render images on import to CCMS (storing source image too)
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
Use a config file format
— there will be
tweaks!
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
Results
By applying IA techniques to graphics transformations…
…we get a pushbutton solution that’s vastly more efficient.
2 minutes tweaking × 50 images per publication × 3 outputs × 10 languages =
50 hours
As with move from DTP to structured authoring, content developers may feel less control
But automation creates space, time for real design work
…and gives customers all the info they need,
where they need it.
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