At the end of the 1990's I made a personal push-back against using slides in presentations, as I was tired by poorly designed bullet-points presentations. For around a decade, I gave keynotes with no slides at all. In the last year or so I've started using slides again - primarily inspired by watching my colleague Neal Ford who turns the dreaded slide-deck into a genuine enhancement to his talks (and is collaborating on a book project to pass on his techniques). As I've been working with slides again, I've also been thinking about what makes a set of slides an effective part of a talk. Thee main principle I've tried to follow is to think of them as a visual channel that complements the audio channel which is my spoken words. I find that thinking them of separate channels in this way helps me avoid common problems with presentations - many of which are rooted in the commonplace bullet point slides.

Most presentation mavens will tell you to avoid bullet point slides, but that leaves the question of what should should go there. When I think of a complimentary visual channel, it makes me think of what visual elements will match my words. This means that the visual channel needs to make the same point, but in a different way.

Saying the same thing differently implies getting away from words on the slide - or at least words that take much attention to read. That's one reason why bullet point sentences are out. But I find words can work, providing they are just words not sentences.

The common approach these days for post-bullet-point presentations is to use photographs. I've derided this by saying that stock photos are the bullet points of the 21st century. By this I don't mean that photos are always wrong, but they often seem to be very unconnected with the speaker's words. I get the impression of many hours spent crawling the internet for some photo that tenuously goes with the talk. (And please, if you use photos, make sure you credit the photographer.)

What I tend to use most is simple diagrams. I try to find some arrangement of simple graphics (and words) that through their visual positioning can help to illustrate, and thus better explain, my words.

Here's a somewhat random example that I picked from my Essence of Agile talklet.

At this point in the talk I'm describing the plan-driven approach to software that the creators of agile were pushing back against. My actual words that go with slide vary depending on the day I give the talk, but they hit these points:

(In a plan driven world)

• The software development activity depends on having stable requirements
• Most of the time, the stability of requirements is questionable
• The plan-driven community knows that requirements stability is hard so explicitly seeks to stabilize them
• Stabilization techniques include up-front requirements, change control boards, and sign-offs

In my talking, I don't verbally state the techniques, instead leaving that list for the slide to illustrate. I think a list of examples is best left to the visual channel.

I've shown this slide as a single graphic, but when I give the talk the slide builds up over a sequence of slides and builds, with me timing the builds to match what I'm saying. This is an example of another aspect of my approach to the visual channel - using motion. Of course it's not uncommon for people to use animations on slides, but too often these animations are gratuitous sizzle that are there purely to show off the capabilities of the presentation software. I've no problem in using sizzle, but I try to always match an animation to what I'm saying, so that the animation can be part of that semantically rich visual channel.

An example here is what I do with the slide after this one. That slide is very similar to this one, just showing an earlier point in the build sequence (the point of software development depending on requirements stability). Most of the time I just use a simple fade to transition from one slide to another, but in this case I'm starting to discuss the agile approach to dealing with this dependency. As a result I do a fancy 3D cube rotation animation, to illustrate the point that we are changing perspectives into the agile world-view. Whenever I switch between the plan-driven and agile world-views in the talk, I do a 3D cube rotate. That transition is eye-candy, but when used this way I think it's eye-candy that helps communicate the point I'm making.

I think that since we have animation available to us when doing presentations, we should use it to enhance the visual channel, providing I can do this in a way that fulfills the role of the visual channel. That role is to keep the eyes engaged in an activity that supports my words without distracting from them.

As I've been using slides again as a visual channel in my talks, I've been making use of animation with diagrams to help communicate my points. The major presentation programs (Keynote and Powerpoint) have long supported animation, but I've been inclinded to look for motion grahics tools that are more powerful and easier to use.

The two main ones that come up in my searching are Adobe's After Effects and Apple's Motion. Both tools are very capabable, but also very expensive: effectively costing about $1000. I got hold of a trial version of After Effects which was a good way to get a feel for it. Infuriatingly I can't do the same with Motion since Apple don't provide trial versions of their software.

One of the directions I was interested in persuing was making use of 3 dimensions. This led me to experiment with Blender, which is a open-source 3D modeling and animation tool. I ran into two main problems, which made it much slower to work with than After Effects. Firstly thinking in 3D is more difficult, and I'm not sure the results are usually worth the extra effort involved. Secondly the UI for blender is very idiosyncratic, which made it frustratingly difficult to do even simple things.

One of the frustrations for me here is that all the tools I've been looking at so far do lots of things that I'm not so interested in, which makes it harder to use them for my main purpose.

I've not seen myself as an iFanboy. I didn't get an iPhone for ages after it came out, and only got one because it was the only way to upgrade my data plan to 3G. I use a mac, but I also have an Ubuntu desktop. But I have got an iPad, and I think it's a significant product.

I knew I wanted one right from the announcement. A while ago I used my desktop for work and kept my laptop floating about the house. I liked that arrangement as it allowed me to get away from my desk for reading the web and doing email. But now that I use Keynote, Aperture, and Omnigraffle I need to use my Mac with a big screen. So my laptop is stuck on my desktop while I'm at home. To compensate I bought a cheap laptop. But using a laptop like this was always kludgy. The clam shell is awkward when I'm reading rather than typing. The low battery life means I try to keep plugged in as much as I can. So a few weeks ago I splashed out.

The Good

• The form factor and low weight makes it comfortable to use on a sofa.
• There's enough battery life that I can forget about it as long as I charge it overnight.
• The screen is gorgeous: bright, clear and sharp.
• The touch UI is familiar (due to the iPhone) and works really well on a tablet device.
• Reading books using the Kindle app works really well. I don't miss having a paper book and I appreciate the lighter weight.
• Web surfing is mostly very good. I find myself using the news apps from BBC, New York Times and NPR a lot.
• It's good for watching a movie. (The Netflix app could be really big here, although I haven't used it yet.) I appreciated the mix of reading and movie watching while flying back and forth to San Francisco in a middle seat; not to mention the fact that I used less than half my battery in the process.

The Bad

• I worry about the lock-in when buying an electronic book. So far I'm thinking Amazon is less likely to lock me into a specific platform than iBooks. But I do worry that I'll have lots of books that I can't read any more some day.
• Web-app sites, such as Google's, often don't work too well. For regular use they make good use of the difference between hover and click - and this doesn't work with the iPad. This pushed me to get an app for reading my news feeds, even though I like Google Reader.
• Like with my Android phone and the iPhone, it's awkward to sync some text or html files from my other computers to my iPad. This is annoying as I like sharing information this way. Dropbox may be the answer, we'll see.
• Hotels with restrictive wifi are a real pain. I want to work on my laptop with wifi and use that nice Netflix app on my iPad. Paying for wifi is bad enough, being unable to use it on multiple devices is awful.
• While it's ok to look at my inbox, the mail app doesn't work well for threaded discussions on mailing lists.
• I would really like to be able to change the font size in the web browser.

The Puzzling

• Apple gets a lot of heat for being a curated software system, rather than the traditional open one. Given how much of my life I've lost to sorting out software incompatibilities I'm not sure whether to like curation of not. In any case the competition with Android and the like will prove interesting.

The Bottom Line

After a few hours with the iPad, I realized that I was feeling a sensation I'd only remembered once before: back in 1995 when someone showed me the World Wide Web. There's no dramatic new technology, we've seen tablets before just as we'd seen hypertext before. But the overall package was game-changer. I don't know if the iPad will be The Device, but I do think that this kind of device will make huge difference to how we read and watch things in the future. I certainly need to work at making sure what I produce in the future is built with these kinds of devices in mind.

One of the most striking things about the Manifesto for Agile Software Development is the format of its values "we favor x over y". I don't remember who came up with that idea, or how it arose. It probably just bubbled up as we tossed around ideas. But it's distinctive format has led a few people to try using that format again.

If you fancy trying this form, there's a couple of things to remember about it, things that people don't always realize. The most important of these is that the unfavored values are valuable too. A phrase like "solving world hunger over slavery" doesn't carry much power because hardly anyone is openly in favor of slavery. The format works when both left and right sides of the "over" are valuable things that most people want. What the comparative values then say is that we want both things, but if push comes to shove we prefer the one on the left. The harder choice there is between right and left, the better the value statement.

So a good mental test is to imagine someone reversing each value statement, indeed reversing all that you have in the set. There should be people that you can imagine proudly and reasonably supporting that opposite position. In our case we saw much of the industry heading towards high-ceremony processes - reversing the values we felt fairly summed up the values of that community. I can easily imagine writing an article extolling why the reverse set of values are a coherent world-view for software development by putting myself into that mind-set.

The right-hand values may be the current state of the world you want to change, or they may be a future state desired by another community. Either way the comparative values are there to highlight the contrast between one and the other.

Another point about the manifesto that I like is its brevity: four comparative values and twelve principles. It's hard to get that kind of brevity, but the briefer you make it - the punchier it is. I'm sure the manifesto would have not had the impact it did if it had forty-six value statements.

I'm one of those who has used this format since. Done well it can really highlight what makes a particular philosophy different to another. Here is another sample, a set of values I wrote to describe how I saw ThoughtWorks as being different from other software organizations.

• Leveraging bright people over Making the most of moderate people
• Flexible career paths over Well-defined roles
• Delivering business value over Leading edge research
• Learning new technologies over Mastering established technologies
• Solving difficult problems over Increasing market share
• Learning from mistakes over Avoidance of taking risks
• Delivery to the client over Quarterly results

We've since replaced this list with another set of principles which try to capture how we want to be. But we did use the comparative values for a while to try to explain both to ourselves and others what made our aspirations different.

As such I think that not just is this format a good way to sum up a world view, when done well it also leads to sharp discussions about what people really want to care about. This usefulness comes directly from the fact that you are making hard choices between things that are all desirable.

I don't not write much production code these days, but I still spend quite a few hours writing code. This code is a particular form of code, meant for explaining ideas in books. Book code isn't quite like real code, there are some different forces to consider when writing it.

One question is the choice of language. I need to write code in a language that as many of my readers can read and follow. I try to write about ideas that are platform independent, but I need code to be precise. So I need to pick some widely readable language that people can follow.

In my early days the two largest OO languages were Smalltalk and C++. Both had faults, Smalltalk was too weird for non-smalltalkers and C++ was too full of sharp edges to get right. Java was a godsend for me. Anyone with a C/C++ background could read it. Even most smalltalkers could hold their noses and understand what I was coding. That's why the refactoring book was in Java.

Later on .NET appeared. The nice thing here was the C# was mostly the same as Java, so I could use the two pretty interchangeably. I liked to use both to reinforce that the ideas I was writing about were useful in either case.

That situation is getting more difficult these days, particularly with writing about DomainSpecificLanguages. Java and C# are diverging, and some things I want to illustrate require features that neither of them have. I do much of my personal programming in Ruby, which is very well suited to DSLs, so I will use Ruby as my first choice for this situation. But other languages have contributions too. I need to balance illustrating various language capabilities for DSLs against letting the book become a hodgepodge of language tidbits.

Another issue with book code is to beware of using obscure features of the language, where obscure means for my general reader rather than even someone fluent in the language I'm using. A good example of this is that when I write examples using Ruby, I've often shied away from using CollectionClosureMethods, even though I use them heavily in my own Ruby code. This is because I consider that programmers from a curly-brace background will find it harder to understand those kinds of expressions. So I sacrifice fluent Ruby in order to reach those readers.

Again this is much harder for a DSL book. Internal DSLs tend to rely on abusing the native syntax in order to get readability. Much of this abuse involves quirky corners of the language. Again I have to balance showing readable DSL code against wallowing in quirk.

Last week I got the newest book in my signature series: xUnit Test Patterns by Gerard Meszaros. I've been working with Gerard with it on and off for a couple of years, so I'm fairly familiar with its contents, but somehow seeing the physical copy gave me quite a shock. Somehow it hadn't dawned on me how big the book was - 883 pages, easily the biggest book in my series.

On the whole I'm not keen on big books, I was very proud of keeping UML Distilled so small. A book this big scares me, how will I ever get time to read it?

But xUnit Test Patters isn't as scary as it looks, because it's actually two books in one set of covers. In this it follows a style I also used in P of EAA. The first book is a narrative book, designed to be read "cover to cover". The narrative book is something small enough to be digestible, in xUnit Test Patterns it's 181 pages, 106 in P of EAA. The second book is reference material, which is designed not be be read cover to cover (although some people do) but instead to be dipped into when needed. The idea is that you read the narrative book to get a good understanding of the field, then put it on your shelf so it's handy to grab when you need to delve into the reference section.

I read a lot of history books and I've often wished that the author had written a duplex book. History books often need detail to expand upon a particular topic or to describe the evidence for a point of view. The result, however can be a long book. One example is a favorite book of mine: Guns, Germs and Steel. I'm really glad I read it, and I do recommend it. But it did feel long, and I wonder how it would have worked in duplex.

How to Read a Book suggests that when you read a book for the first time you should deliberately skip-read it, unhesitatingly skipping over detail sections. I read very fast, which helps me, but although fast or skip reading is a plus, I'd rather the book was designed to help. My personal rule of thumb is that 200 pages is the limit for a narrative cover-to-cover technical book. If it goes over that you need some way to allow people to get the core information with less bulk. A duplex book isn't the only way to it, such as selected bolded paragraphs in the Timeless Way of Building, which worked pretty well for me. I'm sure there are other techniques that I haven't run into yet, but the duplex is currently top of my list.

A duplex book is really a specific case of a more general principle to organize a book in gradually increasing sections. The Pick Axe is a good example of this. The first two chapters are a quick overview of ruby in 24 pages. Then you have 280 pages of tutorial, followed by 500 odd pages of reference material. The first few chapters of the Enterprise Integration Patterns book is an overview (95 pages) with rest (~550 pages) reference. Books like this often don't make these successive layers of revelation as clear as they might, however.

An interesting question is whether we can do more with the duplex book format. A lot people won't realize that xUnit Test Patterns is a duplex book because it looks like one thick book (the back cover actually claims it's three books by considering the reference section as two separate sections). Could we physically split the books, perhaps by packaging them as two volumes in a slip case? I don't think actually selling the books separately would make sense as they are too closely coupled together.

Naturally we think about online access. Reference material often works better on the web, so perhaps we could make the reference book web only (maybe with a CD or something in the physical book) and sell only the narrative book. What would that structure do to sales?

There's interesting questions here, but the final message is that I'd urge authors of big books to think more about how the book is structured in a way that helps someone who wants something within that 200 page limit.