Anna: question for the illustrator

[Jeanne Boyarsky]

HI Anna,
I don't think I've ever met an illustrator for a tech book before. That's cool!

At what part in the process are you involved? Design time? Or translating napkin type drawings into nicer things? Or something else?

And does that change because you know Ben in real life?

[Anna Evans]

Hi Jeanne,

In my case, it comes from a history of working with Ben on a mixture of training and conference materials.

Way back before we were married, he talked me into creating an animation that showed the parallel generational garbage collector in action – so the first few Java conferences I went to with him, I knew very little about Java in general, but could talk for hours about the nuances of garbage collection!

Over the years, we've developed a whole suite of illustrations, and alongside that a sort of visual language that works well for these kind of diagrams.

Which is mostly coloured boxes, and it's amazing how much you can show just using coloured boxes... but the trick of the trade is picking the *right* coloured boxes!

So some of the illustrations in the book are tried and tested ones that I've developed and refined over several years of training use, and have repurposed for the book – because there's no point reinventing the wheel.

(As an aside, I love that developers reinvented the 'reinventing the wheel' saying and called it 'not invented here' instead!)

Some of the illustrations are based off ones that already existed in our library, but where the existing illustrations didn;t quite work to describe the concept being discussed in the book.

Coming back to garbage collection, I have an existing template than I use for most of my parallel GC illustrations, but some of what we were showing in the book was new material, and so I needed to add to the existing representations. For example the attached illustration shows what happens when dealing with arrays in memory, which was something we'd not needed to explicitly show in the past, so I needed to find a way of showing contiguous blocks of memory.

And some of the illustrations are brand new and drawn specifically for Opimizing Java, but using the existing visual language (those coloured boxes again!)

In all cases, the original illustrations had been created in keynote, so I also redrew everything in illustrator which is a more appropriate for creating files for print. I did originally start to try to translate the illustrations into black/white/greyscale – which was tricky as the colour helps convey a lot of information in some illustrations – but luckily O'Reilly made the call to publish the book in full colour, which has made a big difference.

(Thank you O'Reilly!)

[Anna Evans]

In terms of process, it's actually quite similar whether I am working with Ben, or with any of my other clients... and yes, it most commonly starts with napkin scribbling of one kind or another!

Sometimes the client has a clear idea of what they think a diagram should look like. They may already have something scribbled down themselves, or be able to show me existing diagrams that they feel don't quite tell the whole story or make things as clear as they'd like. (Ben sometimes finds himself talking about topics that aren't covered in his existing slide deck and when that happens he'll scribble diagrams on a whiteboard – he'll then take photos of the whiteboard and bring them to me so I can create something to fill that gap in the deck.)

Other times – especially when they're wanting to illustrate a process, or a concept – they may not have a clear picture themselves of what that might look like visually. So at that point I'll usually sit and discuss the concept with them, and get a sense of what's happening. The key is often bringing the process being illustrated down to really simple basic concepts: is something being created? Is one thing changing into something else? Does this thing happening make that thing happen, or is it the other way around? Or "I know these are abstract concepts, but do you see this bit as happening *inside* that bit, or outside of it?"

Conversations like this are important to narrow down the core concept of what you are trying to communicate.

One of the biggest pitfalls when trying to create these kind of illustrations is trying to show too much, or explain everything in one go. So you often need to strip out everything that isn't crucial to that one thing you're trying to explain *right now* – it's often far easier to understand a series or sequence of illustrations that each tell a bit of the story, rather than one ridiculously busy one that tries to show everything at once.

However you need to balance that against not oversimplifying so much that you badly mislead people about what's *actually* happening, or giving them so little information that you may as well be saying 'a wizard did it.'

(We do actually have a 'a wizard did it' animation in Ben's slide deck – we use it for things like explaining some of the more complex Scala operations to people who are just beginning to pick up the language – 'We'll get into this properly later on, but for now let's just say a wizard did it.')

The other thing that is key is establishing a visual language, and as far as possible being consistent with that language. So for example, if I've used a square blue box with rounded corners to show an object in a queue, then I'll try to make sure that any future diagrams that show queued objects, those are also blue boxes with rounded corners. I'll try to use similar colours, shapes, styles of line, types of arrow, etc consistently to represent different things, or concepts, or features, so the illustrations become easier to 'read' the more you see of them. Type is also part of this – always using one font for code, and another for labels makes diagrams far easier to read at a glance.

However, there are always times when following your own rules will make the illustration harder to understand, rather than easier, so you have to know when to break those rules and do what works best for what you are trying to show right now.

When working with Ben I have the advantage that I am in charge of his visual brand, so I'm working with a style of drawing that is purpose built for creating these sort of illustrations... because I built it that way!

With other clients it may be they have existing illustrations and graphics styles I need to work within, so at times I must balance what I think would be the best way to show something against what already exists within their brand. (And in some cases, a client may not have any kind of existing style so I'll develop one for them as part of the illustration process.)

[Bear Bibeault]

Thanks for these posts, Anna! As someone who illustrated his own books, I found then interesting and informative.

I wish I had had the luxury of color print books! As it was, I ended make two versions of each illustration: one for e-books in full living color, and a gray-scale version that needed to be tweaked to try and get across the same concept without the benefit of color.

Have a cow for each post!

[Jeanne Boyarsky]

Thanks for the thoughtful posts.

As an aside, I love that developers reinvented the 'reinventing the wheel' saying and called it 'not invented here' instead!)

I hope you also enjoy how we use multiple terms for the same thing. "reinventing the wheel' and "not invented here" are both common.

While I couldn't give you the custom title of "author", I did just give you the custom title of "illustrator".

[Anna Evans]

Thank you for the title, and the wonderful welcome here... AND the cows! 

And Bear, you have my sympathies... before we switched to a colour print, I was tearing my hair out trying to work out exactly how many shades of grey I could manage to cram into one illustration before they all started to merge into grey goo!