Earlier this year, we announced a new book by SparkFun Education Technologist Derek Runberg: The SparkFun Guide to Processing. Processing is a free, beginner-friendly programming language designed to help non-programmers create interactive art with code. Over the course of the book, readers learn the basics by drawing simple shapes, move on to photo editing and video manipulation, and ultimately affect the physical world by using Processing with an Arduino. We're excited to have the book for sale on our site and the No Starch Press site, and we asked both Derek and Pete Holm, SparkFun's senior designer, who was responsible for the illustration and design of the book, a few follow-up questions about the experience.
Hi Derek! Congratulations! Now that you're finished with the book, do you have any new insights about the process since the last time we spoke?
Where do I start? I never thought writing a book would be so much reading! Towards the end of the writing process I read the book cover to cover about three times. Each time I found something new that wasn't quite right. No Starch Press even had me review the index...yes, I even read the index. The editing process is tedious and extremely detail oriented, which to be honest, is not my strength. I want to give a huge shout out to Jennifer and Alison and their staff for being patient with me throughout the whole editing process. If you ever end up writing a book with No Starch Press, you are in the best of hands and their attention to detail, patience and input is astounding.
Never underestimate the work that goes into images you see in a book. Pete spent countless hours capturing all of the screen shots, drawing the diagrams and illustrations and annotating the images in this book. Each image and their caption goes through the same editing process as the writing does. Image dimensions, resolution and clarity/ colors all go through the ringer. In the end, the final product is an aesthetically beautiful book. I owe Pete more than a few cold ones!
Finally, I had never thought about the amount of content that doesn't make it into a book. You always hear about scenes cut from movies, songs that don't make an album and so on. I've never thought that books have a similar body of content that doesn't make the cut for a number of reasons. For this book there are two chapters that were cut. One was cut due to the length of the book, the other was due to the project not aligning with the rest of the book. I have a plan for this content...be on the lookout for the "writers cut" in the coming months.
Who would you recommend this book for?
The book is dedicated to educators. They are the first people to come to mind when I try to answer this question. The book is formulated around a number of Processing activities I designed for my students during my time as a middle school teacher. Knowing that, it is a perfect fit as an informal text book for the classroom, and can easily be adopted as a curriculum for a computer science or technology class at the middle or high school level. The content in the book could easily span an entire semesters' worth of projects.
Beyond the teacher, I would recommend this book for anyone who has thought about learning how to program, and maybe purchased a few books and got two chapters in, before giving up because the learning curve was too steep or the material was just too dry and boring. The book is designed with the idea of getting your feet wet in writing code and creating a lot of cool things with it. I throw formality and what you "should learn" out the window, and in its place I write about what you need to know to make something cool. The focus is on the making and the tools and materials to do so, not theory and academia. If you have never tried programming, I recommend this book for you. I ease you into it in a similar way that your mom may have hidden your vegetables in a smoothie. After a few projects you will find yourself looking to explore other possibilities and dreaming up ways to make what you produce better.
Thanks Derek! Now let's see what Pete has to say.
Hi Pete. What was it like designing/illustrating a book (for the first time?)?
My day-to-day duties at SparkFun don't really involve a lot of illustration work, so it was definitely a chance for me to stretch those creative muscles a little bit. I don't have any delusions of joining the ranks of the Chip Kidds and the Peter Mendelsunds of the world, but it sure did feel good to be a part of that industry even just for a little while. I'd do it again for sure if I didn't have this whole other job I like.
What was the hardest part?
I think I went back to the drawing board on the cover artwork three or four times. Derek was never a hard sell… he was on board from the very first concept and he was preoccupied with a whole other bucketful of problems. But it turns out, making a publishing company happy is a whole lot harder. I get the feeling No Starch has forgotten more about what does and doesn't make books disappear from shelves than I'll ever know. It's really hard to hear that something you've worked on for hours and hours "just isn't quite right," but knowing when to abandon an idea instead of continuing to fiddle with it is an essential part of the process. In the end, I think their fastidiousness helped me produce a really worthy cover.
What was your favorite part/illustration?
Making illustrations that are primarily based on screenshots can sometimes throw you a curveball that's pretty funny. For example, figure 9-2 isn't a particularly interesting illustration, but for me it was. I had to figure out how to take a screenshot, which typically uses a keyboard command, while Processing is displaying a totally different key input. You can't have the caption read, "displaying the ASCII code and characters for CMD+CTRL+3." I know it seems weird that I'd find something like that funny but listen, I've got 3.91G of just screenshots here that say, "That was a fun day."
What advice would you give someone who wants to become a book designer/illustrator?
I don't know if I'm prepared to call myself that in any official capacity, but ok lemmesee… The best advice anybody ever gave me was to not get hung up on your tools. Yeah it's nice to have a big fancy tablet and the latest versions of Photoshop and Illustrator, but that's not where the ideas come from. Some of my best concepts have come from a pencil drawing I scratched out at a boring meeting. Having the power to CTRL-Z every little mistake can really get in your way without you knowing it.
It can also be hard to accept that what you want isn't necessarily going to be what your client wants, and there's a distinct possibility that you're the one who is going to have to adapt to the situation. That often means not getting exactly what you want in a final product. In the case of the Guide to Processing, I think in the end everybody was happy (I certainly am), but it's not always going to be that perfect "Starsky and Hutch" sort of relationship. It's more of a "Turner and Hooch" situation.
Oh! and make sure you make time to draw for your own satisfaction from time to time. It'll make you better person, not just a better artist. That goes for anything you enjoy doing, really, not just drawing.
Thanks for the insight guys, and congrats on the new book and all your hard work!
Thanks!! Looking forward to sharing fun projects with the community!
Dear Chelsea, thank for inspiring content! Considering how quickly interest in programming is growing among the younger generation, the release of such books is an incredible success for all of us, especially students. The SparkFun Guide to Processing is a very visual and introductory textbook for writing code for those who were not familiar with programming at all. I am studying cybernetics and I know how difficult it is sometimes to 'get involved' in the essence of any knowledge from the field of development.
I purchased the book several weeks ago. I've thumbed through it and it looks to be a well written and useful addition to my library.
Looking forward to the "writer's cut", also.
It's one of the ironies of our age that massively powerful systems that have centuries of work hours in them are free, while the book that tells you how to use it (with only a few years of work hours) costs infinitely more. Literally. Try dividing $29.95 by 0 - you get infinity.
I'm not complaining, I'll probably buy the book when I get enough of an order accumulated to get free shipping (and I've certainly forked over enough money to O'Reilly for Linux books over the years), just saying what a weird situation we've gotten into.
Interesting indeed, but I think it goes to more of the ease of accessibility.
I've always wanted to write a technical book for makers to help them get into FPGAs and enjoy the problem solving it comes with. I would want to release for free by self-publishing and letting them download it. However, a problem I see every time I look at it is, promotion/accessibility.
You self-publish, you have to promote it yourself. You don't get the structure that a well-known publisher has to promoting and distributing the book. Even for digital books, this is key. Not to mention, the book can only be accessible to where you want it. People will always copy, try to get credit for something they didn't do. Not to mention, the publisher will help fight any lawsuits/protection.
So that's my opinion. I could be completely wrong on all fronts, but that's what I've seen when I started writing my book (which will most likely never get finished/published).