: How do you explain the details of something technical to a non-technical audience? When writing about technical topics it is often difficult to get across the complexity of a topic without getting

Vote Up Vote Down

Elegance is unavoidably beautiful, but implementation details are tedious at first. I'd not give a section on motivation followed by a section with more details as much as I'd have the whole thing following gradually and naturally from fascination you've built about the subject.

For example try drawing a loop with a smooth curve. This may be on a piece of paper or by using a loop of string. The loop can pass ocer itself as much as you like as long as there are no places where three lines meet in exactly the same place.

I might now pose a question or three, which may if your lucky (hint, this is mathematics) turn out to unexpectedly and inexplicably be related:

Given the loop you've drawn can you add a square somewhere, oriented and sized as you wish but so that all 4 corners touch the sides of the loop.
Can you notate each crossing to show what line passes "over" and which passes "under" the other.
Can you colour/label each region "black" or "white"?

Obviously you can't always do these things. Except (surprise) it turns out that you always can, so you can start taking this for granted and move on.

Perhaps now an algorithm could be written to calculate the specifics of the above 3 points given a specific loop, how?

Properties can be used to find other properties, this is a property of properties. Another impressive example with loops involves hanging picture around a given number of pegs. This can be done by looping the string above the picture back and forth over and under the pegs to ensure that when another given number of pegs are removed the picture falls. For example 5 pegs, any 3 of which must be removed.

How are things like this, and anything else you may wish to understand and do worked out? One approach involves translating any specific loop to another rearrangeable mathematical object, specifically you can change any specific loop into an equivalent equation. In the case of the colouring example we may well want instead to use graph theory.

The above was only an example, but at this point you probably want to know yourself. I think a lot of knowledge is very naturally like this. Start with high level ideas, and build to "Blah corp recommends you do the calculation in this order" level details with your readers interest.

(0)

Vote Up Vote Down

I'm personally hostile to analogies and "dumbing down", because it can have the unintended effect that people take the analogy too far, or get stuck with the dumbed down version.

Your goal is to show the complexity, but without overwhelming the audience. You can do that by providing multiple layers.

In the main part of the text, speak mostly about consequences, leave out technical details: Encryption ensures the confidentiality of documents because knowledge of a key is needed to decrypt and thus read the document. This layer is written for the non-technical audience and should require no technical knowledge to understand. You would explain, say, the difference between encryption, hashing and cryptographic signatures, but not how they work.

Then you provide an option for the reader to study the topic more in detail, e.g.: see Appendix B for recommended encryption schemes.

Then in the appendix, you can dig into more technical details, e.g. which encryption algorithms and keylengths are recommended. This layer is written for a technical person or a person with basic technical knowledge, someone who can stomach technical terminology and a little bit of math. You would explain the different algorithms and their application, how to correctly use them and technical details of methods, but not explain the algorithms themselves.

Again, for the very low detail, like how ECB differs from CBC or why the CV is important except in those modes which use a nonce... you refer to footnotes or endnotes or another way to hide the third layer out of the way of the immediate text flow.

And if you want, you can add a fourth layer where you actually explain how AES or DH, etc. work. Though that layer has already been written by others and you could just refer to it.

You can apply the same principle to implementation details - the top layer speaks to the user, describing what the software does. The second layer speaks to the system administrator describing how to install and maintain it. The third layer speaks to the developer and describes the source code, how to modify it, etc.

The basic idea is to provide the details, but move them out of the way so that a reader not interested in them (or afraid that he'll not understand) can skip over them easily. The best way to accomplish that is to not have them in the main text. Appendices, footnotes, etc. were all invented for this purpose. You can also add a "technical part" at the end with individual chapters and refer to those. All you need is some references (back and forth!) so the reader who does want to dive into the details can quickly find his way back to the main text.

(0)

Vote Up Vote Down

When explaining concepts of any kind to an audience unfamiliar with the knowledge domain, the following methods are highly effective:

analogy & metaphor - compare (albeit inexactly) what this thing does to how that thing does whatever (in computer software, hardware, and services (among other fields), there is the ever-present "car comparison")
stories - humans are highly story-oriented beings (it's used in selling, teaching, programming, history, math, etc etc)
the three pitches (there are variations, like this one, too):

30 second :: aka "elevator pitch" - get someone excited enough to want to keep listening/reading
300 second :: you've got their attention, don't lose it; go into a little more detail - but don't overwhelm
30 minute :: you really want people to buy-into what you're telling them

Communication is like selling - it's all about return on investment. And ROI is all based on understanding abstractions (and how they leak). You need to give the reader/listener enough of a promise they're going to get value at least proportional to the time spent consuming what you're trying to convey that they want to stick around.

Guy Kawasaki promulgates the "10/20/30 Rule of PowerPoint" (in direct relation to pitching to venture capitalists, but the general premise carries into most other realms well, too):

no more than 10 slides
no more than 20 minutes
no font smaller than size 30

If you cannot convey the core basics of what you want your audience to "get" in a few minutes with [the equivalent of] a few bullet points in an easily-followed (ie "large font") manner, you're [probably] not going to be very successful in "communicating".

Once you've accomplished the levels of "hook" you need to get your audience to want to continue through, keep it up: there will be boring aspects of what you need to convey - don't skip them, don't dwell on them too long, don't lie about them, and don't over-simplify them - but try to make them as short and interesting as you can.

(0)

Vote Up Vote Down

The tactic I use most often for this is analogy.

By creating an analogy to a commonly understood topic, you can introduce the core ideas in a way that feels familiar to the audience.

That said, coming up with a quality analogy can be difficult and possibly take a couple of attempts. It doesn't need to be perfect, though, it just needs to lay out the basic structure. Knowing where your analogy doesn't work is about as important and knowing where it does, since those points are where you possibly have the most opportunity to drive home what makes your topic unique and complex.

(0)