kickingbear

iBooks Author is a tool designed to enable authors of instructional, and other interactive content, to format their work specifically for distribution on iPad devices. In time these parameters may change but, for now, this is the purpose that iBooks Author serves.

If you are authoring your content directly in iBooks Author then I suggest to you that you’re doing it wrong. Create your work as you would have previously and then approach the idea of publishing it on the iBookstore as an opportunity to spruce up your presentation with interactive elements.

iBooks Author is a tool that allows you to leverage specific advantages of the iPad and iBooks 2. It is, categorically, not a tool for creating cross-platform “electronic books”. If you’d like to create those then Apple will be happy to provide a first-class experience for them. If you’d like to do something above and beyond that then consider iBooks Author.

Why the hell they opted for a restrictive EULA when they have such a terrific pitch is beyond me.

The iBooks Author EULA has been in the news recently. It has, in fact, bumped Romney and Gingrich out of the headlines and it’s all anyone is talking about. Everywhere. I just received an email from a lovely Nigerian professor who’d like to send me millions of dollars because he fears the iBooks Author EULA will confiscate it from him if he publishes his text book on implementing cold fusion. (Drinks on me at Macworld!) Allow me to scale this mountain of a molehill and defuse this tempest in a teapot.

There is an across the board consensus that the iBooks Author EULA, as currently written, is overly vague and can be understood to apply broadly to any and all content generated by the application. From there commentators fall, roughly, into one of two camps: Restrictions on output are inherently wrong and; The EULA as written will never be enforced. It’s not even that the two camps are in a real disagreement, it’s that one camp is dealing with the facts as they are now while the other is reading into the intent and projecting a better outcome.

I’d like to say that I’ve not seen an argument regarding this EULA that I disagree with but that’s not the case. I will say that I’ve yet to read a well reasoned opinion on the matter that I wholly disagree with. As a matter of personal opinion I believe that the intention of the EULA isn’t to restrict the distribution of text or PDF files generated by iBook Author. As written the EULA does suggest that they are. This should be clarified, as everyone else has already said.

The interesting thing, to me, is in the reactions we’re seeing. Let’s project this EULA issue into the software world and consider it in those terms. A new piece of Apple software has shipped and it exhibits behaviour that the vast majority of the most vocal users find to be faulty. The behaviour is a bug. What do we do?

To me the obvious course of action is to complain loudly about the bug and hope that Apple addresses it. (And file a Radar! Always file a Radar!) But we then get into the issue of intent.

I’m in agreement with Mike Ash and Dan Wineman — intent doesn’t matter when considering the practical implications of the choices that have been made. That said intent does matter if we’re hoping to read the tea-leaves to devine what might be. When examining what we believe to be faulty behaviour the perceived intention is invaluable. It’s the difference between a bug and a feature. A bug we expect to be fixed, a feature we expect to have to live with. Lion inverted scrolling.

I think the issue that hasn’t been addressed that is really at the heart of this is: why is iBooks Author free? The arguments for legally tying the output of iBooks Author to the iBookstore is that the application is free and that through sales of for-profit books Apple will recoup it’s investment. That’s very true and again I don’t disagree with that. My question then is, why does it have to be free? What’s wrong with the old-fashioned model of asking for money for something of value? If Final Cut Pro XII came out for free but required distribution via iCloudVideo would that be acceptable? It strikes me that the good old-fashioned buy-your-tools-and-your-work-is-your-own model works quite well. This change to giving away free tools but locking down (legally) what you can do with them doesn’t sit right with me.

The rebuttal is that there are plenty of tools that are de facto locked to their platforms. That’s true and it’s a good argument. Xcode basically only makes iOS and Mac OS X software. Visual Studio is similarly platform specific. But those are technical limitations, not blunt legal limitations.

My position is that there’s enough laws in place as it stands to prevent competitors implementing the functionality that’d be required to have, say, a Kindle Fire run (experience!) an iBooks Author generated .ibooks file. Now, obviously, I’m not a lawyer so what do I know, but if the future is platform specific content generation tools, locked down with legalese, then I think we’re going in the wrong direction.

(No really, I get the last word on comments because none of you jerks are allowed to comment on this piece)

From my own About Page:

For technical pieces I keep comments open because dissenting views or outright corrections are incredibly valuable if they’re in the same place as the source material. For opinion pieces, which seems to be the bulk these days, I’ll be closing comments.

My position is that if you’re presenting technical or data-driven analysis then commentary on the same page is invaluable. If you’re expressing your opinion with regards to data or current trends then immediate commentary on the same page is far less valuable and, most likely, will simply be argumentative. Take it up on your own forum.

Don’t make me comment all over your site about this.

The iPhone mute switch functionality has been doing the rounds. Here’s Marco Arment on “Designing Mute”.

I almost entirely agree with Marco. This part caught my attention however:

The user told the iPhone to make noise by either scheduling an alarm or initiating an obviously noise-playing feature in an app.

The user also told the iPhone to be silent with the switch on the side.

I’m not sure this line of argument is entirely true given the push possibilities that are part of Exchange, iCloud and various other services. Is it possible someone else has pushed a reminder to your device that you’re not explicitly aware of? (Really, I’m asking, and I’m too lazy to find out. Someone tell me. In my comments. Which I don’t have. See my next post.)

What I do know for sure is that if the mute switch on the iPhone worked as Andy Ihnatko argues it should then I would be unable to use my iPhone as an alarm clock. I get far, far too many emails and notifications late into the night and early in the morning to not mute my iPhone before I go to bed at night. I’m quite sure that Andy, Josh, Marco and everyone else having this discussion likely faces the same problem.

I don’t know what the answer is. I do agree with Marco that the default suits my needs well and I appreciate the design choices. I also agree that it’s telling that it’s been years before this iPhone arrogant design flaw came up. I’d bet $100 that this happened already during some kid’s birthday party at a Chuck E. Cheese but nobody got all up in arms when the teenage wait-staff got bust out of their “Happy Birthday” groove. (Do they do that at Chuck E. Cheese? We don’t have those in Canada. We love our children.)

Anyway, feel free to fire away with your comments in the form presented below. I will sleep soundly knowing that both my iPhone being on mute, and the fact that there is no comment form, will prevent me from hearing the chimes of the incoming emails and allow me to rest soundly, knowing that my iPhone will dutifully wake me up sometime around noon.

One of the rules I have when I consider writing a piece for Kickingbear is that it must be, to my mind, something contrary or a worthwhile addition to the discussion. There are many fantastic writers out there covering the same topics, their thoughts and conclusions most often align with my own. I decided that I didn’t want to say, “me too”. I thought that if I was going to take the time to write a piece here that it’d be at least something new, or probably contrarian. (Though sometimes I cave to being a jackass).

I find myself in disagreement with two terrific friends of mine. Both have been incredibly supportive of me as I came up in this community and both were gracious enough to speak at the Çingleton event I helped organized a few months ago. Brent and Daniel are good friends, good people and landed Mac gentry. So, let’s skewer them.

Jalkut wrote this piece, Learn to Code. Read it, it’s well worth your time. Simmons linked to Jalkut’s piece adding this, “I’m reminded of Matt Mullenweg saying ‘Scripting is the new literacy.’ Matt’s right.”

I appreciate where they’re coming from. I can, from a certain perspective, agree with the argument. But, let’s not kid ourselves, literacy is the new literacy. The ability to read, comprehend, digest and come to rational conclusions — that’s what we need more of. We don’t, as a society, need more people who have the mechanical knowledge to turn RSS feeds into Twitter spam. We don’t need anything more posted to Facebook, we don’t need anything we photograph to appear on Instagram and Flickr. If “scripting” is the new literacy then we’ve failed. We’ve become Mario drowning on a Water Level.

Scripting isn’t the new literacy, it’s the new tinkering with the engine, the new re-wiring the house. The new DIY for the digital age. These sorts of skills are incredibly valuable, but they’re not now, and certainly won’t be in the future, anything close to being an art form that stirs our souls.

That’s what literature does — it communicates to humans by leveraging our understanding of words and our grasp of narrative. And, sometimes, it mixes them all up but we still get value from it. That’s not how writing code works. Writing code is a craft, we build upon the capabilities of the compiler, the libraries and the hardware. We don’t have the freedom to innovate, as an author would, unless we control the whole stack. And we don’t. We swim upon a shallow surface, we perform what amounts to an act of synchronized swimming. At times it’s beautiful, but we’re in a pool, and we can’t control how wide or deep it is.

If you’re reading this, it’s probably too late. I’ll say to you — don’t Learn To Code, just Learn. Whatever it is you’re good at, whatever it is that calls to you — do that. And do it again and again and again and again.

Learn to X.

Code. Write. Draw. Build. Design. Bitch. Moan. Complain.

Learn to do it well.

Writing software is a craft. I’m quite good at it. Brent and Jalkut are also very successful at our craft. But it’s a craft. It’s something we’re really good at but, in my opinion, it’s not something that everyone needs to care about.

So, don’t Learn To Code, go and learn something I don’t know anything about and go and do it incredibly well. If you’re brilliant and new then I’m dying to see what you can do.

If you really would like to learn how to program then Code Year seems to be amazing. I’ve been volunteering for over fifteen years to help train people who want to become programmers. I believe in teaching people how computers work. I don’t believe it matters much more than wood-shop.