What is Larry Thinking? #29 => E-Commerce, Flex, and Self-Publishing

June 24, 2010

In this edition…

About This Newsletter

This newsletter turned out to be a peek into the future and, well, rather self-serving. I compile these newsletters largely based upon what I’ve been working on lately or thinking about, and this time around this largely means what I have been publishing, or am about to. So while I try not to make this newsletter too much about me, I’m consoling myself with the thought that you’ve subscribed to this newsletter because you’re interested in what I’m doing. The newsletter has three big topics, related to books past, present, and future: Flex, E-commerce, and JavaScript. I’ve also thrown in a couple of other references, for variety. If you make it all the way to the bottom of this read (it’s long, even for me), you’ll find out about my “Effortless Flex 4 Development” giveaway! As always, thanks for your interest and please share any questions, comments, and winning lottery numbers you may have…

On the Blog => “E-Commerce with PHP and MySQL” Table of Contents

I’ve posted the first draft of the table of contents for my next book, “E-Commerce with PHP and MySQL”, on my blog. The post starts with some background information as to what I’m hoping to accomplish and then outlines the individual chapters, some more than others. I would love to hear any feedback and thoughts you may have on the structure, as you’re the target audience!

On the Web => “Five Flex/Flash Builder Tips in Five Days” Blog Posts

Peachpit Press, on their Web site, is in the process of publishing two series of “Five Tips in Five Days” blog posts that I have written. One is on the Flex 4 framework and the other is on the Flash Builder IDE. As of this writing, nine of the ten posts have gone live with the other one expected tomorrow. All of the posts are written for those with an understanding of Flex 4 and Flash Builder, respectively, highlighting new or less-known features and concepts. But even if you aren’t familiar with either, you may want to take a gander at them to get a sense of what Flex 4 and Flash Builder are capable of doing. The best way to access them is through my reference page at Peachpit’s site.

On the Web => The Open Standard Media (OSM) Player for HTML5

In my previous newsletter, I highlighted two HTML5 video players that I’ve come across lately. Well, ironically, one reader of this newsletter has been working on an HTML5 player as well, called the Open Standard Media (OSM) Player. As the name implies, this tool is open-sourced, making it even more enticing than the others I’ve seen. If you check out the Web site, you can see the player in action. The player is also theme-able (using jQuery’s ThemeRoller), so you can better integrate it into your Web site. Great work and thanks for pointing it out, Shaun!

On the Web => A Roundup of 15 Mobile Web Design Tutorials

As I’ve mentioned before, I’m not much of a cell-phone person (I have one, but most days it doesn’t get turned on and my wife is pretty much the only one that has the number). Although this means I’m a bit of a dinosaur, it’s not really a problem, I feel, except that more and more Web sites have created mobile versions, so being familiar with Web development for mobile devices is necessary these days. I recently came across a post of 15 tutorials with respect to creating a mobile version of your Web site. The tutorials are a good place for people to start learning this subject.

Q&A => What are the practical benefits of learning JavaScript for a hobby web developer?

Johan had asked me this question, adding that his impression was that JavaScript was a language “that seemed to be given little ‘serious’ attention after early 2000.” I don’t think Johan is alone with this impression, but JavaScript is a very important language these days and this (mis-)conception is part of the reason I’ll be writing my own JavaScript book.

When I first started learning Web development (in the late 1990’s), JavaScript was a toy language, largely used for annoying purposes. Honestly, about the most practical use of JavaScript was image rollovers and popup windows. Alerts were annoying, but common, as were status bar tickers and so many tedious cursor tricks. But JavaScript has come a LONG way since then and is definitely worth knowing. JavaScript’s progression is thanks to many changes, like the improved support in browsers, the increased usage of broadband Internet, and the development of several excellent frameworks such as jQuery. Today, JavaScript—real, serious JavaScript—is used quite legitimately by all the top sites. But how about some examples, just off the top of my head?

First, JavaScript now has a worthwhile impact on the look of a site, along with developments in CSS, of course. And JavaScript can be used to improve a site’s security, like the obfuscation of email addresses so they aren’t written in plain text format, free for any bot to read. More importantly, JavaScript is now being used to greatly improve the user interface and experience. Starting with client-side validation, the user input can be validated as they enter it, saving them from a full page reload to find out that a username is unavailable or that they failed to enter a required field (server-side validation is still obligatory for security purposes, however). And JavaScript is used for things like image viewers that display a larger version of a picture without requiring an overt server call or a new browser window. Then there’s the biggie: Ajax. Thanks to Ajax, the clunky client-server interaction is now sharp, streamlined, and professional. I think about Netflix, which I’ve used for years: when I used to go manage my queue of movies to rent, it was one long form. Into the various text inputs, next to each title, I would enter what the new queue value should be, then submit the form to reorder the list. But now when I go there, I can click an icon to instantly move an item to the top of my queue or click and drag other titles around. It’s much easier, faster, and intuitive. All thanks to JavaScript. This Ajax connection between the browser and the server means that traditional server-side developers now have a need to learn JavaScript, too.

The problem I’ve found is that most existing JavaScript books fall into one of two categories. The first are legacy titles that have been around since JavaScript was a joke and have been updated time and again. These are okay, but, like trying to update your decades-old car with each new feature that comes along, the result can be a beastly, unorganized mess. The second category are advanced JavaScript titles that accurately demonstrate what JavaScript’s capable of today. People like John Resig, the creator of jQuery, have written books like these and they’re great, but not for everyone and they certainly don’t teach the language from the ground up (they are more akin to my PHP 5 Advanced book, which assumes intermediate knowledge of PHP). So my JavaScript book, which I hope to write this fall, will teach today’s JavaScript as it’s actually being used, written for beginners so that they understand it not just as a series of recipes but also as a whole programming language.

Q&A => What is the target group of Flex and why would one start with Flex?

Johan also asked me this question, along with the parenthetical of “rather than just out of curiosity”. Well, curiosity is one valid reason—it’s why I do many things, but there are two better ones, I think. First, if you acknowledge that Rich Internet Applications are at the crux of the Web today, then developers need to know how to create them. There are really two broad options for generating RIA’s: Flash and Ajax (JavaScript/HTML). Ajax is great and certainly worth considering, but can be tricky, time consuming to develop, and somewhat unreliable across multiple browsers and operating systems. Flash can be created in many ways, too, from a graphical, time-line approach using Flash Professional to programming Flash content using Flex. And there are non-Adobe frameworks for generating Flash content, as well. On the bright side, Flash content will behave the same on all browsers and all operating systems (assuming they have the right versions of the Flash Player plug-in installed, but users will be notified if they need to upgrade and the plug-in is already installed on 98% of all browsers). Although I think we’ve heard about certain Cupertino-designed mobile devices that won’t run Flash at all, so there’s that to consider if you’re developing for mobile users. As for Flex, it’s just an amazingly fast way to develop Flash content. You can really create elaborate applications in a fraction of the time it would take using Ajax. And because Flex is a framework, it’s a pretty easy thing to learn for current programmers (like PHP developers). If you can do HTML and JavaScript, you can do Flex (there’s a strong parallel between how Flex works and HTML/JavaScript).

Just to be clear, I’m not suggesting that Flash is better than Ajax or vice versa. There are pro’s and con’s to both. Personally, I think knowing multiple technologies and then choosing what you want to use is a much better route than just using what you know because that’s all you know (if that makes sense; for example, you can use PHP to perform command-line scripting but there are better technologies for that purpose). So learning Flex puts another tool in your toolbox. On a recent Web site I did, I used jQuery-based Ajax on the public side of things and Flash on the administration side. I made that choice in this case because the administration got to be complex and would have been hard to do in Ajax but was easy to do in Flex. Conversely the public side had much simpler requirements and a splash of jQuery was all that was required.

Another reason to consider Flex is you can use it, thanks to Adobe AIR, to create desktop applications. Not that many people are using AIR, as far as I can tell, but I think it’s great, especially for creating administrative apps. My first experience with Flex was when I rewrote an Ajax-based AIR application I had previousloy created as an in-house utility (I use it to publish errata on my Web site, among other things). In literally one day (maybe even an afternoon) I was able to re-create a program that had taken me several days to do using HTML and JavaScript. And the Flex version added new features! And (here’s the kicker), I saved that much time before I actually even knew how to program in Flex; I was just hunting around for the right components and bits of code on the fly. If I were to rewrite that program again today in Flex, it’d probably take me maybe three hours, including debugging.

What is Larry Thinking? => Testing the Waters: Self-Publishing

I’ve wanted to write a book on JavaScript for some years now, like maybe six or seven, and people have been asking for me to write one for even longer. (As an aside, a huge thanks to everyone interested in my work and to those who recommend topics they’d like to see me pursue, such as JavaScript or e-commerce.) Of course, pretty much every publisher has at least one JavaScript book out already, including the publisher I normally work with, Peachpit Press (and publishers try not to cannibalize their own books or writers), so for a long time it seemed like doing a JavaScript book wasn’t going to happen. Then, last winter and spring (of 2009), I went through several discussions with a publisher that did not yet have a JavaScript book. In talking with them, I came up with a full proposal and table of contents for a beginner’s guide to today’s JavaScript. But that publisher was relatively small and very deliberate when it comes to deciding to do a title. After jumping through one-too-many hoops, I decided that my working for that publisher wouldn’t be a good fit (and that was really the right decision), so now I’m left to self-publishing this JavaScript book.

Ten, even five, years ago, self-publishing wasn’t a realistic option and generally wasn’t a route that established writers choose. Before e-publishing, it was too much of a financial risk to print some thousands of copies of your own book. Plus you’d then have to store those somewhere and manage all the shipping yourself, when you were lucky enough to sell a copy. There is a “print on demand” option, where single copies of books could be printed as needed, but few legitimate books are manufactured this way. Now, thanks to the rise of e-publishing, everything has changed, making it not only feasible but practical for writers to self-publish. In fact, Amazon is really pushing writers in this direction, providing a service to turn electronic versions of books into Kindle-friendly versions. My plan, then, is to write this JavaScript book and publish it for free, in its entirety, online in HTML format. I also plan to sell electronic copies—PDFs, Kindle versions, etc.—for a cheap price. For PDFs, my plan is to sell at a user-determined price (i.e. pay what you think it’s worth); for other electronic versions, I’ll have to see what makes sense. I’m very excited about finally writing this JavaScript book and about testing the self-publishing waters, but what does this mean, exactly?

When you write a book for a publisher, you’ll get a guaranteed advance of $5,000 to $15,000 (US), depending upon the publisher, the book, and the writer. Even if you never sell a copy of the book, that money is yours to keep. You then earn a percentage on each book sold (to bookstores, not necessarily to readers), and that percentage is first deducted from the advance. In my experience, I get from less than a dollar per book (for translated or non-US sales) to a bit over two dollars per. So if you assume an advance of $10,000 and royalties per book averaging $1, then I would make $10,000 for the sales of up to 10,000 copies. And, in my experience, 10,000 copies qualifies as good, but not great, sales. (By the way, that $10,000 is for three to four months of work, and I have to pay all my taxes out of it, so if you think you can get rich writing books….)

Conversely, when you self-publish, you get no money up front at all and you’re actually doing a lot more work, so there’s a risk involved in terms of time lost (time when you could have been doing paid work!). On the other hand, if I charge, say, $10 for an electronic copy of the book, then I only need to sell 1,000 copies to be at the same point as I would be selling 10,000 copies of a physical book. The ratio is good, but there are other factors…

Publishers provide well more to the writer than just an advance. There’s the project editor, whose job it is to shepherd the book along, provide suggestions for organization, and make sure the book fits in with the series (if applicable) and styles of the publisher. Then there’s the line editor, who goes through the book editing grammar, checking consistencies, and making suggestions in places where the meaning isn’t clear. There’s also the technical editor, who’s an expert in the field and validates the accuracy of the code and text, as well as making suggestions for improvement. And those people are just for improving the content. A compositor takes the text, code, and images and turns them into proper pages. An indexer creates the index. And then all the marketing people sell the book to bookstores, events, and so forth. It’s safe to say that in almost every case, working with a publisher results in a better book and you have people, to some degree, actively trying to get bookstores to buy the book.

By self-publishing, I’ll be sacrificing these valuable roles (unless I felt like paying someone out of pocket to perform these jobs) and will need to be extra vigilant myself to ensure the quality of the work. Plus I’ll need to do my own marketing, which is not my forté (and that’s part of the reason why I intend to make the HTML version freely available). On the other hand, I won’t have a deadline, although that’s not necessarily a good thing! Another key difference will be the lack of a page count limit. Publishers factor in the number of pages in a book when they calculate its price: a book with more pages is more expensive to produce and ship. But a book’s price is driven by the market. Whereas publishers used to be rather lenient when I went over the intended page count (which happened frequently), they’re tightening the reins more and more. This means that I need to choose carefully about what does or does not go into the book. Without a publisher, the book won’t have that restriction, although this could again be a mixed blessing.

I’m very excited about this self-publishing opportunity (“opportunity” in the sense that I’m making this happen for myself) and will be curious as to how I feel about the endeavor when all is said and done. But one of the great things about working for myself is that I can try new things, take risks, and adjust my habits to an ever-changing marketplace and technical arena.

Book Giveaway=> “Effortless Flex 4 Development”

You must be subscribed to the newsletter in order to qualify for the book giveaway.

Larry Ullman’s Book News => “Effortless Flex 4 Development” and More!

There’s a lot going on in my office, obviously. I’m very pleased to say that my “Effortless Flex 4 Development” has just been printed (I received my copies two days ago, so it should be in bookstores soon). I’ve been looking through the hard copy and I think it turned out well. It’s not in the Visual QuickPro/Start Guide series that I’ve mostly written in, so the format is less constricting and I think there’s more content in there because of that. It’s definitely geared towards PHP developers, but is written for complete beginners to Flex and Flash. Amazon is currently selling it for $29.69.

The second bit of news is my “E-Commerce with PHP and MySQL” book, which I’m officially working on now. As mentioned earlier in the newsletter, the table of contents are online for public viewing. I’m currently doing a bit more research into what I want to do (for example, selecting the second payment gateway), and starting to work on the code. My plan is to put live versions of both sites online and will ask for feedback on those in the next newsletter (I hope).