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.

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.

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.

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.

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.

Wouldn’t that be nice? Here’s how Apple can do it.

I’ve done a lot of thinking about the Apple TV. For some reason it fascinates me. It’s entirely different from the other applications of software. First, it’s a shared experience rather than a direct experience like a Mac or an iOS device. Second, this shared experience means there’s necessarily an indirection of input — if a screen is big enough to be seen by everyone in the room you’re not going to be close enough to it to mess with it directly. So when the rumours went around of an iOS based Apple TV coming I became intrigued and tossed some ideas back and forth with a friend. Mostly the discussion came down to input methods — what could they do and what’d that mean for the interface? Around that same time Bluetooth 4.0 was ratified and the specification includes a low power mode. I guessed that if the Apple TV had a Bluetooth 4.0 chip then we’d see a new remote, if not we’d likely just stick with what we had.

Well, it turns out the new iPhone 4S has a Bluetooth 4.0 chip and since all of these devices, broadly, share a generational common platform we can expect to see it appear in the next iteration of Apple TV. So that’s one part of the puzzle. My guess is for the new remote is a touch sensitive surface with a mic that’s activated by holding down on the Select button. That’s my guess at least, if you can’t play with these things it’s hard to know how they’ll actually work.

But there’s a lot more going on with my hypothetical Apple Television Set than just a fancy remote. There’s no wires, there’s the box finding the display and there’s joining the network effortlessly. How can all of that happen? I believe it’s all possible thanks to the details in this report by Nilay Patel writing for The Verge.

I like this report because it’s a little forlorn — the intent is to convey that AirPlay won’t be enabled over Bluetooth contrary to previous rumours. But buried in here are, to my mind, major clues to technology that will change the value proposition of an Apple Television Set.

Patel:

Made For iPhone accessories have to be authenticated by iOS to work, and the new chip is an authentication module that works over the dock connector, AirPlay, and Bluetooth.

Sounds perfect for an authentication system that’d be required to stream protected content wirelessly to a display. We’d need that if we were going to build my hypothetical Apple Television Set. So the Apple TV box and the Display could find each other via Bluetooth and authenticate with each other. Since you’re very unlikely to be plugging in three sets of these things within Bluetooth range of one another the odds are good that you don’t need to worry about selecting specific devices. And in the cases where that might happen well just read the Tech Note that tells you to do them one at a time. But we’re still at a loss about how we can connect to the WiFi network so easily.

Patel:

We’re also told Apple is making it easier to for MFI accessories to connect to Wi-Fi networks by automatically pulling the appropriate configuration information from your iOS device over Bluetooth or the docking cable — all you have to do is approve the request and your accessory will hop online without any extra effort.

So if you’re in an Apple based household the odds are good that your new Apple TV will be able to talk to one of your other devices and get the required network info from it. I’d bet heavily that this capability makes its way into AirPort devices and Macs. “Want to let this device on your network?”, is exactly the level of simplicity that Apple tends to aim for.

I think the pieces are coming together to make an Apple Television Set an interesting and worthwhile proposition. The Apple TV box device finds and communicates with the Display seamlessly. The control channel between the Display and the Apple TV box is based on a low power Bluetooth 4.0, the Display doesn’t even need an on/off button since it draws so little power. Once the Apple TV box has turned on the Display it feeds it video via AirPlay over the WiFi network. The HDMI inputs on the Apple TV box are displayed in the interface just like other sources of input, like NLB or NetFlix.

The beauty of this sort of setup is that it disconnects the iteration of the Apple TV box from the expensive Display. One key argument against Apple doing a television set has been that people buy new TVs infrequently and so it’d take a long time to break into the market. By building an Apple TV box that can act as it does now but also deal so much more magically with a terrific television then Apple can gain traction selling the devices and accrue additional sales in a new market as users buy into the whole device chain.

I’d believed the idea of Apple doing a television set to be a little far fetched or, at least, something I couldn’t see the value of. With the new information to hand I feel like there really could be a compelling product there. Not, mind you, a blow out success like the iPhone or iPad, but something solid and sustainable.

Oh, and in the impossibly thin bezel of the Display would be a FaceTime camera.

“People who are really serious about software should make their own hardware.”

I don’t blame them. I agree and I think it’s totally true.

And then they say that Nintendo should start developing games for iOS.

Don’t be too proud of this technological terror you’ve constructed. The ability to control the interaction direction of an entire industry is insignificant compared to the power of creativity.

Nintendo was founded in 1889. Despite all the bad news I’m still pulling for them. And you should be too. If you like companies that take risks, introduce innovative hardware and software combinations, and back up their visionaries with everything they’ve got — pay attention. It’s ugly right now but there’s still fertile ground for a new hope. Unless, of course, you’re happy with all the players who are chasing the last great interaction rebellion.

I wanted to ask Blodget a few questions about this piece that he’d written for Business Insider. It appeared to me like he was talking out of his ass.

I did, as they teach you in journalism school, try to reach out to Mr. Blodget for his comments.

Here’s the audio recording of my communication with Henry Blodget.

By press time this publication has yet to receive a response from Mr. Blodget.

The danger you have as a savvy, professional, 90-percenter software developer looking to build a cottage industry business in the world of app development is that if you come home after a busy day and you have a wife, three kids, a box-set of Battlestar Gallactica and/or The Wire to enjoy, you’re likely to run out of puff pretty quickly trying to get up to speed with iOS.

The real danger you have as a savvy, professional, 90-percenter software developer looking to build a cottage industry business in the world of app development is believing you’ll find success without skipping a lot of TV shows.

I don’t think Baxter-Reynolds is mis-prioritizing at all, in fact spending time with your loved ones and relaxing after a long day with some good entertainment sounds like a wise way to live one’s life. It’s just at odds with building a successful cottage industry business of any kind, mobile software development included.

Of the successful smaller developers I know, and I know many, I can’t think of one that hasn’t at one point or another completely overextended themselves in order to put the time into their product or business that it required. And I mean overextended by stretching themselves to learn new technologies, new ways of marketing, the fundamentals of running a business but also by just simply spending far too many hours working at it. To do that you’ve got to love what you’re doing, there’s no two ways about it.

If you follow the calculus of Baxter-Reynolds’ piece you’ll find yourself working at home, late into the night, with technologies and toolchains you work with at the office. I doubt you’ll love that but I suppose it’s possible. If your goal is to churn out some interesting smaller application ideas and throw them into an online store then maybe a minimum investment is what you’re after. If you’ve got a burning to make something remarkable then dipping your toe in the water won’t get you across the alligator filled moat of hard work that’s between your day job and something self sustaining.

I won’t rush to defend the iOS toolchain against his complaints, I think Gruber largely nailed it with The Unfamilliar. I will call out Baxter-Reynolds’ argument that only 6.1% of programmers are using Objective-C compared to 60% who are using “other languages typically used for building internal-use business applications” is “a good barometer of where the industry is in the terms of platforms that are being developed for”. In terms of sheer man hours? Perhaps he’s right. If we scaled those numbers by which language was used in the most admired pieces of user software we’d see a drastically different picture. The truth of the matter is that currently the most admired client side user facing software is written in Objective-C. When that changes or when one and two man shops working in some other language out maneuver Cocoa developers (as Cocoa developers did to others) then I’ll be happy to have a talk about effectiveness. Until that’s happening I’ll continue using Cocoa, Objective-C and C to write software that has been enjoyed by tens of millions.

The stylus will never be the primary input device and the interface will never be designed around the precision that it affords but, in a few years, I believe that the sensors embedded into the iPad, and possibly the iPhone, will enable a greater input fidelity through the support of stylus style devices. Touch events will expose the touch radius they already track but they’ll also expose the pressure, angle and device identifier. For a finger the device identifier will be nil, the pressure will be a constant, the angle will be a constant and the touch radius may be exposed in device specific units. For a stylus device the device identifier will represent a unique nib for the pen tip or eraser of each stylus pen, pressure and angle will be determined just as they are now when using a Wacom tablet on a Mac. I know for a fact that major enterprise customers in the graphics field already rely upon the touch radius that isn’t yet exposed publicly. To expand the use cases of iOS Apple will need to support higher-fidelity input.

That’s not to say that iOS will ever require a stylus type device. I’m simply arguing that within a few years iOS devices are likely to support input mechanisms that afford a far greater fidelity than simple touch input.

I’ll go on the record as betting Joan Gruber that within five years we’ll see an iOS device that supports a stylus natively, but not as a necessity. I see the stylus starting as a thirty dollar accessory targeted at markets that require the additional fidelity.

The brush has been around since the earliest cave paintings; fidelity of input will become a killer feature.