A month ago I was contacted by PacktPub with a “Review Request” and was provided with a ePub copy of the book for this exact purpose. PacktPub – which I had never heard of before – apparently is trying to get traction on the iOS developer market with a dozen books on the subject matter. But this pales in comparison to the hundreds of books they published for non-iOS ecosystems (Microsoft, Web, Java, etc.)
Is it just me or does it seem like more and more iOS developer are hoping to supplement their living from getting book royalties?
At the end of my procrastination I sat down and forced myself to read the first half of the book, taking notes to give this book a fair and balanced review. A word of caution: this will be a tragic comedy of epic proportions.
In Austria we have a saying: “Nothing is useless, it can always serve as a bad example”. It is my hope that this bad example serves to improve the overall quality of literature on our favorite subject matter.
The title of the work suggests that this book is not meant to be read in a linear fashion. You’d expect from a “Cookbook” to find “Recipes” for individual things that you would look up should you need to cook them. In the chapter about the book’s copyright you can read:
Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied.
So far so good, but who is this book meant for? In the words of the author:
The iPhone Interface Cookbook is written from the ground up for people who are new to iOS or application interface design in general. Each chapter discusses the reasoning and design strategy behind critical interface components, as well as how to best integrate each into any iPhone or iPad application. Detailed and straight-forward recipes help give guidance and build understanding far beyond what is offered through Apple’s Human Interface Guidelines.
From these two parts of information – and possibly the short author’s bio – you come to expect a highly polished work that may sit on the shelf of a fledgling iOS developer getting his feet wet on his first couple of apps. A reference manual for design, if you will.
This puts me at odds with the premise. Neither am I fledgling, nor am I designer. I love to code and generally I like to delegate designing UI and UX to the companies that hire me. After having realized this I gave the book a second chance in my head: if it is worth the expense maybe I could recommend it to those designers sitting in my client’s companies for reference?
As an iOS contractor you often have to deal with companies that have established themselves on non-iOS platforms and now – due to public and marketing pressures – they also want an iOS app. Generally their in-house designers will know how to design a Windows app or website. Often I have wished for being able to recommend to them a guide as to what they have to do differently when designing for our platform.
This book isn’t that either.
Maybe I was “holding it wrong” because I read the book from the front cover to slightly more than half when I had to abort the mission. I’m detail oriented by nature and so I found boatloads of errors, formatting problems and blatant omissions with which I filled a note on Evernote with.
For example this is how e-mail addresses are formatted throughout. What do you think if you see this?
At first I attributed the problems I was seeing to the ePub format. Apparently the publisher did not invest in this being properly edited. Neither from a formatting point of view nor in terms of technical correctness.
Each chapter in the book slavishly follows this structure: Getting ready, How to do it…, How it works…, There’s more…, See also. The general style hides some interesting information in a tone ripe with fluff and half-truths.
And what’s even more annoying is that these mini-sections all take up space in the index which is destroying that as well. In this example you can see the worthless index. Why in god’s name would I want to directly jump to a There’s more in a section? You have no way of quickly getting an overview of what “Recipe” would be the right one for a real-life design case. Except wade through these superfluous entries of sub-sections.
I admitted that I am probably a) not the right person and b) not reading it correctly. But the problems with this book go far beyond the formatting.
Somehow I am getting the feeling that the individual chapters in this book might have been articles on a blog, that somebody just copy/pasted together and replaced all instances of “article” with “recipe” and “blog” with “book”. Is that truly the way how modern developers expect their information to be diced?
For one thing you’d expect from an experienced iOS developer to know how to spell the name of our IDE correctly. Instead Cameron (or is it a lawman editor?) insists on spelling it XCode. This book couldn’t have been edited on a Mac because even my WordPress autocorrected that to Xcode. Purists might call this a blatant disregard for what is holy.
There are many more examples of misspelled classes, apps or terms we iOS developers deal with every day. To give a second example: WebKit is one word, not two.
Ok, there are formatting problems (ePub’s fault), there are technical editing problems. To top it off there are factual problems as well.
The author details how to generated certificates on the provisioning portal, but omits the simple information that you can just connect your device via USB, click on the “User for Development” button in Xcode Organizer and have Xcode auto-provision the device in your “iOS Team Provisioning Profile”.
Then there is much commingling. Alert Views are thrown in together with modal view controllers. Later they are mashed up with push notifications and local notifications. And the rationalization for why everything is modal: “iOS is a highly modal operating system, forcing one application at a time upon the user.”
There are 4 step guides where the second and third step are identical, just worded differently. There are in-depth explanations about topic that a designer has no interest in, and the interesting topics are covered incompletely. In truth I found two or three nuggets of information buried deep in what I read. For example I found the explanation on Fitt’s Law quite interesting, didn’t know that.
Sooner or later you realize that the statement from the Copyright section is a lie. “Every effort” was definitely not made and the information isn’t presented at an acceptable level of “accuracy”.
The second promise that the publisher did not keep is who the book is for. Where are the explanations “far beyond” of what you can find in Apple’s HIG? Where are the chapters that I can recommend to the UI/UX designer working at my client’s?
I had to stop reading half way through, when I had accumulated 3 screenfuls of “bugs”. I am not getting paid to correct this book, so that amount exceeded the level of bullish!t I was willing to put up with. My job is to evaluate whether this work of art is worthy of your attention.
By now you should fathom my opinion.
Categories: Reviews
