Hiptype offers third-party analytics for eBooks...with a catch

PaidContent reports that Hiptype, a company that offers third-party analytic reporting for eBooks, has launched. Amazon, Barnes & Noble and other eBook vendors can gather a variety of information about how their eBooks are read--how far a reader gets into an eBook, how often they open it, what notes and highlights they add, etc. However, that information is rarely shared with publishers. Hiptype allows publishers to independently gather similar information. The information is anonymized, but consumers can opt-out of Hiptype's data collection completely (assuming, of course, that they know that Hiptype is collecting information.)

There's a huge hole in Hiptype's data collection that may make it unattractive for most publishers: It requires eReaders that support both HTML5 and JavaScript in order to work, but according to paidContent, neither web-based eReaders like Kindle Cloud nor desktop eReaders, even those that are browser-based, will work. Black & white eReaders are also unsupported. That limits the usefulness of Hiptype to Apple's iBooks and a few iOS and Android eReading apps. Frankly, I'm surprised that they even released the service when its practical value is so low. This isn't a Minimum Viable Product--there's virtually no value in the current offering for most publishers.

They're offering a 30-day trial with service for one book, or programs priced at $19 or $99/month. The $19/month program is limited to 1,000 readers, so it's not useful to anyone other than self-publishers and very small publishers.

eBook Wars: Browser Wars All Over Again

At the IDPF Digital Book 2012 Conference earlier this week, Michael Tamblyn, who's Kobo's Executive Vice-President for Content, Sales and Merchandising, gave a status report on his company's market success and progress in implementing an EPUB 3-compliant eReader. Mr. Tamblyn said that because there are "a half-dozen ways to do anything in EPUB 3," it's essential that his developers test Kobo's EPUB 3 prototype using live samples, but his company is having difficulty getting enough document samples for testing. He also said that some publishers are waiting to actually get commercial EPUB 3 readers in-house, so that they can develop their documents to use the features actually implemented by eReader developers.

The next day, I spoke to a manager from a document conversion and app development company on the BEA show floor. He said that his company recommends to publishers that they use EPUB 3  as the basis for creating eBooks. I asked, "But what about Amazon? They don't use EPUB 3." The representative said that Kindle Format 8 is "very close" to EPUB 3, and that Amazon might adopt EPUB 3 in the future. In any event, he said, it's fairly easy for his firm to convert EPUB 3 to KF8.

The era of "Browser Wars"

I came back from New York with a bad case of déjà vu. Anyone who was involved with the Internet from 1995 on remembers "Browser Wars," the battle between Netscape and Microsoft to dominate the web browser market. The engineering team that developed Mosaic, the first graphical web browser, at the University of Illinois, moved to Silicon Valley and wrote a new browser, code-named Mozilla, that became the Netscape browser. Netscape quickly became the most popular Internet software ever released to that date. Then, Microsoft licensed the original Mosaic code from the University of Illinois and released its own browser, called Internet Explorer.

Early on, Netscape introduced new tags and functionality to its browser at a fast clip. Some of these tags, such as frames, gave web designers more options for creating web page layouts, but the tags were implemented without being adopted by the World Wide Web Consortium (W3C,) the international standards-setting body for the Web. Microsoft adopted some of Netscape's tags and added many of its own. However, even when it adopted a Netscape tag, it would often adopt a different set of attributes (the settings that tell the tag what to do.) There were also variations in how browsers rendered tags: The exact same web page, using the same HTML tags and attributes, in two browsers that supported all the tags and attributes used in the page, could look different in the two browsers. For example, in one browser, the page might be displayed with a background color that bled all the way to the edges of the window, while in another browser, the same page might be displayed with a white border around the edges.

It wasn't only HTML that got "innovated" to pieces. The same scripting language got two different names--JavaScript at Netscape (where Brendan Eich invented it), and JScript at Microsoft. As with HTML, the two companies' implementations were different in subtle (and sometimes not so subtle) ways. This was the era of "Looks best in (Browser X)" and "We prefer (Browser X)". In some cases, web pages wouldn't even open in some browsers, and the user would be told to use or install a different browser.

Browser developers encouraged these differences in order to lock customers in, but they were a nightmare for website designers, who had to design different versions of their sites for different browsers, and even for different versions of the same browsers. Pressure from designers and software developers on browser vendors and standards organizations reduced, but to this day still hasn't completely eliminated, the requirement to do things in different ways for different browsers. The W3C took charge of defining new versions of HTML and pushed vendors to stop implementing their own new tags until they'd been reviewed and accepted by the W3C. The W3C also adopted Cascading Style Sheets (CSS,) which over the years have made it easier to tightly define the layout of web pages that work across browsers. Ecma International (formerly the European  Computer Manufacturers Association) took over standardization of JavaScript, and changed the name of the standardized version to ECMAScript.

However, even with all these standardization efforts, supported in some cases by companies whose annual revenues exceed those of the entire book publishing industry, there are still incompatibilities among browsers, and even among versions of the same browsers. For example, Mozilla has JavaScript in its Firefox browser, and Microsoft still has JScript in its Internet Explorer. Both are compatible with ECMAScript at a basic level, but both have additional features that are incompatible with each other.

From Browser Wars to eReader Wars

eBook designers have a variety of formats that they have to work with: Amazon's .AZW (based on the Mobipocket format acquired by Amazon) and Kindle Format 8 (based on HTML5 and CSS with extensions), EPUB 2.X, Apple's iBooks (EPUB 2 .X with Apple's extensions), Kobo Color Content (EPUB 2.X  with Kobo's extensions,) Nook Digital Replica Plus (EPUB 2.X with Barnes & Noble's extensions,) EPUB 3 (HTML5 and CSS3 with the IDPF's extensions) and PDF.

To eBook designers, the word "extensions" is a synonym for "incompatibilities." Two different eReaders may perform the same functions, but if the tags or attributes that tell the eReaders what to do are even slightly different, eBook designers will have to either design around the differences or not use the functions.

Can we draw lessons for the eBook industry from the Browser Wars years? I think that we can:

1. Incompatibilities among eReaders from different vendors, and even among different generations of eReaders from the same vendor, are inevitable and won't go away.
2. Amazon will adopt EPUB 3 48 hours after Apple provides full support of Flash in iOS. In other words, it'll never happen. Amazon's eBook formats are strategic technologies for the company, and it won't allow any competitor or group of competitors to dictate how a strategic technology must work.
3. Despite the best of intentions, browsers' implementations of HTML5, CSS3 and JavaScript are still incomplete, although they're much less incompatible than they once were.
4. EPUB 3 is based on HTML5 and CSS3, and most eReader developers will either base their software and devices on an existing web browser to avoid "reinventing the wheel," or will use the customer's existing web browser and then support the EPUB 3 extensions with JavaScript. Either case makes EPUB 3 subject to lesson 3 above.
5. In order to minimize time and cost, eBook designers and developers will inevitably gravitate to a "lowest common denominator" approach, where they'll either only use features supported compatibly by the largest number of eReaders, or will design eBooks so that features that aren't supported by a particular eReader are either simulated or ignored without crashing.

Two new HTML5 authoring tools

More than a year ago, I wrote a blog post bemoaning the lack of HTML5 authoring tools. Then as now, you could create sophisticated content using HTML5, CSS3 and JavaScript, but you had to hand-code everything. Now, we have beta versions of two different HTML5 authoring tools that promise to make the process a lot easier.

First, there's Sencha Animator, which focuses on CSS3 effects (transitions, animations, transforms, and anything else you can define in CSS3). It provides an interactive timeline for creating animations with keyframes. Next, Adobe announced the first preview version of Edge, its authoring tool for HTML5, CSS3 and JavaScript. Like Animator, Edge uses a timeline, but it's considerably more sophisticated: The user interface is designed to look and work similar to those of Flash Professional and After Effects, its animation framework is based on jQuery, it natively imports and exports HTML, CSS3 and JavaScript, and it stores all its animations in a separate JavaScript file rather than modifying the CSS3 file(s).

With Adobe jumping into HTML5, the obvious question is whether Edge is a replacement for Flash Professional? Not yet. Both Sencha Animator and Adobe Edge remind me of Swish Max4, an Australian authoring product that outputs Flash but is considerably simpler and easier to use than Flash Professional. Edge is still early in its development; when Adobe releases a new tool like this, it's typically a year away from commercial release. In addition, different browsers implement different portions of HTML5, and it will take time for the most popular browsers to fully implement the specification (which isn't even scheduled for ratification by the W3C until 2014). However, we're getting closer to the point where HTML5 becomes a viable replacement for Flash for a variety of applications.

Given that Adobe is cannibalizing itself with Edge, there's an obvious concern that the company might cripple Edge in order to keep Flash viable. If Adobe was the only company creating HTML5 tools, that would be a legitimate concern, but other companies are competing in the authoring tool space. If Edge creates inferior content, developers and artists will use a competing product. My belief is that Adobe would like nothing more than for Edge to make up for all the revenues that it's losing as Flash is abandoned, and that means that it can't create a second-rate authoring tool.

Adobe and Sencha are working to make HTML5 look and work more like Flash, and additional companies and organizations are inevitably going to release their own authoring tools. We may only be a few years away from witnessing Flash become a legacy application.

Steve Jobs goes on the record about Flash

Apple's position on Adobe's Flash is well-known, from the company's new iPhone Developer Agreement, Steve Jobs' remarks at an Apple "Town Hall" meeting, and a series of emails between an iPhone developer and Jobs. However, Jobs has now gone "on the record" with an open letter explaining Apple's decisions.

I've linked to the open letter so you can read it yourself, but here are the key arguments:

1. Despite Adobe's claims of openness, Flash is a proprietary platform and format controlled by Adobe. Apple's approach is to use HTML5, CSS and JavaScript, all of which are open industry standards controlled by standards committees.
   
2. Adobe claims that 75% of the video on the Web is in Flash format, but an increasing number of sites (including YouTube) also supply video in H.264 format that iPhone OS-compatible devices can use, so the problem is getting smaller every day. Jobs admits that Flash games won't run on iPhone OS, but there are over 50,000 games and entertainment titles already available for the iPhone, so the lack of Flash hasn't caused a problem.
   
3. Flash is the number one reason that Macs crash, and Symantec has reported that Flash had one of the worst security records in 2009. Flash doesn't perform well on mobile devices, and Adobe has been promising to deliver a full version of Flash for mobile devices for almost two years and still hasn't shipped. Apple doesn't want to subject iPhone OS users to these problems.
   
4. Most Flash video uses a Sorenson or On2 codec that requires software decompression, while H.264 can use hardware decompression. In Apple's tests, videos that can use H.264 hardware decompression play for 10 hours on an iPhone before the battery runs out, while viewing videos that require software decompression cuts battery life in half.
   
5. Flash was designed for keyboard and mouse interfaces, not touch, and the iPhone, iPod touch and iPad rely on touch.
   
6. Cross-platform development tools like Flash can't take advantage of new features as quickly as Apple rolls them out, so Flash developers can only use these features after Adobe supports them. Also, cross-platform tools encourage development of  "lowest common denominator" applications.

You may disagree with some of Jobs' arguments, but his open letter is the most comprehensive and clearest presentation I've seen of why Apple has decided not to support Flash.

Don't cry for me, innovation

Today's New York Times website has an article on the importance of maintaining investments in innovation, even with an economic downturn. My question is, what innovation? I track a variety of technology-related industries, and I've been hard-pressed to find anything recently that qualifies as a real innovation. One of Google's most exciting recent innovations is the ability to read and index text in images of pages, such as in PDF documents. I worked for Palantir, the company that invented most of that technology, 23 years ago. Or how about Google Chrome, which was all the rage a few weeks ago? It's largely based on open-source Webkit technology and a JavaScript compiler that Google acquired, rather than developed in-house. And, it's a browser. I was in the browser business near the beginning as well, at Netscape, 13 years ago.

The problem isn't encouraging innovation in an economic downturn, it's producing true innovation, period. Economic downturns often help, rather than hurt, innovation. Just as forest fires burn away the underbrush that stifles forest growth, so companies are forced to focus on products and services that really matter. The survivors in each product segment become clear, and the people who work for the losers either take their ideas to the winners or go start their own companies. A new wave of start-ups is born, and some of them do really interesting things, rather than merely cloning what someone else is doing with a minor twist.

I say let the big companies batten down the hatches, and let the start-ups without business models die off. The big guys will do what they've been doing for a long time, which is buying their best ideas from others. So long as there's venture capital and engineers & scientists driven to build the next big thing, innovation will take care of itself.

Obligatory Google Chrome Post

Yes, I've installed Google Chrome, and no, it's not an Internet Explorer killer, at least not yet. My browser of choice is Firefox 3, and I see nothing in Chrome at this point that will get me to switch. The biggest advanage that I see so far is that Chrome seems to be considerably faster in loading pages than either IE or Firefox. Chrome uses the same WebKit rendering engine that Safari uses, and Safari has been roundly praised for its speed, so it's no surprise that Chrome is fast. Google benchmarks show that Chrome's V8 JavaScript compiler is much faster than the interpreters in IE, Firefox and Opera, but the forthcoming Firefox 3.1 will have its own JavaScript compiler, so Chrome's performance advantage may be short-lived.

It's going to take a long time for Chrome to get the same kind of third-party developer support that Firefox already has, but I don't think that's Google's objective: I think that they're targeting users who want simple, fast browsing, and couldn't care less whether the browser supports add-ons. Click one button and it's installed. Every visitor to Google Search is a potential user. That's got to scare Microsoft, even if Chrome is less sophisticated in many ways than IE.

I've visited some sites that don't recognize the Chrome user agent, and thus either limit access or won't give access to Chrome users at all. Therefore, the onus is now on Google to get site developers to support Chrome. That's not going to be easy, because other than the Google name, I haven't seen anything compelling enough to get most people to switch from their existing browser to Chrome.