Newer posts are loading.
You are at the newest post.
Click here to check if anything new just came in.

February 23 2012

Developer Week in Review: Flash marginalization continues

I got a rude reminder of how dependent we've grown on ubiquitous telecommunications, as AT&T decided to take a sick day, cell phone service-wise. The outage only lasted an hour or so, but I suddenly found myself on the road with no way to call into a scheduled scrum standup (can it be a standup when you're sitting in your car?) and no way to email to let them know what was going on.

Total outages have been pretty rare, but it wouldn't take much from a solar storm perspective to knock everything offline, something I wrote about several years ago. Try to imagine modern society with no power, telecommunications or GPS navigation for a few days, and losing cell service for an hour gets put into its proper perspective.

Now that I'm back at home with a nice reliable fiber connection, I can give you the news of the week.

Tux can only flash people wearing chrome, now

As was reported previously, Adobe is starting to gracefully put Flash out to pasture in favor of HTML5. The deathwatch took another step forward this week, with Adobe announcing that only Chrome will be able to run Flash under Linux in the future.

One could argue that Linux never was much of a market for Flash anyway, but following on the heels of the announcement regarding mobile support, it should be clear that Flash is on the way out. Flash was once considered the last best hope for seamless integration across desktop and mobile platforms, held back only by Apple's intransigence. Now, all eyes are on HTML5.

Getting laid off doesn't sound so bad now, does it?

In the "developed world," software professionals spend a lot of time worried about intellectual property, career viability, privacy issues, and the like — our version of "first world problems." Once in a while, however, we get harsh reminders of the kind of real problems that can face a software developer in less-friendly circumstances.

Such is the case of Saeed Malekpour, an Iranian-born engineer and Canadian resident, who is currently facing a death sentence in Iran, accused of creating a pornographic network. According to most sources, the only thing that Malekpour actually did was to create a program that could be used to upload photos to websites, and that code had been incorporated into pornographic websites without his knowledge.

Malekpour confessed to running a pornographic network after a year in custody, a time when his supporters claim he was frequently tortured. What is certain is that very soon, if nothing is done, he will be executed, likely by being beheaded.

It's easy to write this off as a symptom of extremist ideology, but it should also serve as a wake-up call to open source and freelance developers who never plan to venture outside so-called "developed" countries. It is far too easy to imagine some hapless developer being dragged off to an undisclosed location because his or her software was found on the laptop of a jihadist. The problem with writing software is that you never know who may end up using it.

Putting Apple's labor issues in perspective

I just watched the "Nightline" report on Apple's production facilities, run by Foxconn in China. I'm sure that there's lots of righteous outrage afoot about the low wages (starting at $1.80 an hour) and cramped living conditions at the facility. I thought it was worth putting things in perspective, however.

To make it clear at the outset, I'm not in any way an apologist for China's government or social system. But I suspect you could find lots of people living in the U.S. willing to work for that wage, provided with lodging for $17 a month and a meal that cost about an hour's wage. As the report pointed out, the suicide rate at Foxconn is actually below the average in China, at 1.7 suicides per 100,000. For comparison, U.S. police officers experience 18 suicides per 100,000. And lest we become too indignant about factory accidents at the Foxconn facilities that killed more than two dozen in the past few years, we should remember that the U.S. doesn't have a shinning record in this regard either.

The point I'm making is that Apple makes an easy target because of its size and because some people want to make trouble for the company whenever they can. However, if we're going to attack Apple, let's do it for the right reasons. By most accounts, Apple is doing a much better job ensuring worker rights and safety than the industry as a whole.

Strata 2012 — The 2012 Strata Conference, being held Feb. 28-March 1 in Santa Clara, Calif., will offer three full days of hands-on data training and information-rich sessions. Strata brings together the people, tools, and technologies you need to make data work.

Save 20% on registration with the code RADAR20

Got news?

Please send tips and leads here.


January 13 2012

Four short links: 13 January 2012

  1. How The Internet Gets Inside Us (The New Yorker) -- at any given moment, our most complicated machine will be taken as a model of human intelligence, and whatever media kids favor will be identified as the cause of our stupidity. When there were automatic looms, the mind was like an automatic loom; and, since young people in the loom period liked novels, it was the cheap novel that was degrading our minds. When there were telephone exchanges, the mind was like a telephone exchange, and, in the same period, since the nickelodeon reigned, moving pictures were making us dumb. When mainframe computers arrived and television was what kids liked, the mind was like a mainframe and television was the engine of our idiocy. Some machine is always showing us Mind; some entertainment derived from the machine is always showing us Non-Mind. (via Tom Armitage)
  2. SWFScan -- Windows-only Flash decompiler to find hardcoded credentials, keys, and URLs. (via Mauricio Freitas)
  3. Paranga -- haptic interface for flipping through an ebook. (via Ben Bashford)
  4. Facebook Gives Politico Deep Access to Users Political Sentiments (All Things D) -- Facebook will analyse all public and private updates that mention candidates and an exclusive partner will "use" the results. Remember, if you're not paying for it then you're the product and not the customer.

Sponsored post

December 22 2011

Developer Year in Review: 2011 Edition

This year brought us triumphs and tragedies, new companies born and old ones burning out. Before DWiR takes a holiday hiatus, we're going to look back on the high points of the year that was.

Mobile gains ground


Lost in all the news about lawsuits, patents and speculation was the overarching theme for mobile this year: it has become the primary software platform for many users. The desktop may not be dead, but it's definitely showing its age, and as smartphones and tablets become ubiquitous, the amount of time the average consumer spends in front of a keyboard is declining rapidly.

The good news for software developers is that the maturing app store model has opened up software distribution to a much larger pool of potential software makers. The bad news is that it has also drastically reset the expectation of how much consumers are willing to spend for apps, although prices are climbing marginally. A $1 app can make you a lot of money if you can get millions of users to buy it, but it won't even get you a nice night on the town if you're writing for a niche market.

With RIM's Blackberry market share doing a good imitation of an Olympic high diver, and the new Windows mobile platform not yet gaining significant traction, 2011 was essentially a two-horse race, with Android passing iOS for the first time in new sales. Apple is crying all the way to the bank, though, as the profit margin on iOS devices is pushing Apple's bottom line to new highs and overall unit sales continue to climb steadily. At least for the moment, the smartphone market is not a zero-sum game.

This year also marked the release of Ice Cream Sandwich (ICS) for Android and iOS 5 for the iPhone/iPad/iPod. ICS is the first version of Android that is making serious efforts to tame the tablet situation, but there have been widespread complaints that carriers are slow to pick it up, even in new models. Objective-C developers are finally getting to say goodbye to old friends like retain, release and autorelease, as Apple rolled out the automatic reference count compiler. Few tears were shed for their passing.

Strata 2012 — The 2012 Strata Conference, being held Feb. 28-March 1 in Santa Clara, Calif., will offer three full days of hands-on data training and information-rich sessions. Strata brings together the people, tools, and technologies you need to make data work.

Save 20% on registration with the code RADAR20

The year of HTML5

In future years, 2011 will be remembered as the year Adobe put up the white flag and joined the HTML5 bandwagon, which started an industry death-watch for Flash. Microsoft also sent out signals that Silverlight was being put out to pasture and that it planned to embrace HTML5 as well.

The stampede to adopt HTML5 was prompted, in part, by the increasing robustness of the standard and the implementations of the standard in browsers. It also didn't hurt that it is the only Rich Internet Application platform that will run on the iPad.

Dru-who and Ha-what?

Two packages with funny names became the hot skills to have on your resume this year. Drupal continued to gain popularity as a content management platform, while Apache Hadoop was the must-have technology for data crunching. By the end of the year, developers with experience in either were in short supply and could basically write their own tickets.

Languages emerge, but few stick

It seems like every year, there's a new batch of languages that promise to be the next Big Thing. In past years, the crown has been worn by Scala, Erlang, Clojure and others. But when it comes time to start a project or hire developers, skills in new languages are rarely high on the list of priorities for companies.

This year, Google joined the fun, promoting both Go and Dart. Like most new languages, they face an uphill battle, even with Google's massive resources behind them. Few have what it takes to fight the institutional inertia of existing development decisions and to join winners such as Ruby in the pantheon of well-adopted emerging languages.

Some general thoughts to end the year

The computer industry, more than most others, can make you feel very old at a relatively young age. I've been hacking, in one form or another, for nearly 35 years, and the technology I used in my youth seems like it belongs in another universe.

The flip side of this is that I'm constantly amazed by what science and technology brings forth on a seemingly daily basis. Whether it's having a conversation with a device I can hold in the palm of my hand or watching the aurora light up the heavens, seen from above by occupants of the ISS, I often seem to be living in the future I read about as a kid.

As a species, we may be prone to pettiness, violence, willful ignorance and hatred, but once in a while, we manage to pull ourselves out of the muck and do something insanely great. Let's attempt to honor the vision of an admittedly imperfect man we lost this year and try to make 2012 insanely greater.

Got news?

Please send tips and leads here.


November 10 2011

Developer Week in Review: Adobe raises the white flag on mobile Flash

To err is human, to err publicly is just plain embarrassing. I ran an item in last week's review that turned out to be kinda stale news. How stale? Well, it dated back to the last Bush administration. That stale ...

Moving forward, I'll try to avoid posting "classic" developer news, and keep things on the cutting edge. Such as:

Flash - 0, HTML5 - 1

Flash and HTML5For a long time, it appeared that Adobe Flash was going to become the de facto mobile application development platform. Apple's intransigence to adopt Flash on mobile Safari was considered a major knock against Apple, and when Apple opened the door to AIR-based iOS native apps, it was seen as Apple caving in to the desire for Flash developers to be able to deliver their apps onto iOS.

Somewhere in there, however, HTML5 came along and stole Adobe's lunch money. Adobe appears to have moved on to Kübler-Ross stage five, and has accepted that HTML5 has trounced Flash, at least in the mobile arena. The company has signaled to their employees that moving forward, Flash will not be supported on mobile platforms.

This is a much bigger story than just mobile, however. Mobile web traffic now accounts for 7% of the total, and is growing at a rate of nearly 1% every three months. As tablets become more popular, this number may skyrocket. Web content providers are unlikely to commit to developing web pages that can't be used well by such a growing demographic, and publishers/developers are likely to shift from Flash to HTML5 for RIA development. Adobe has a leg up on other tool chain providers because it has rich integration into tools such as Photoshop and Illustrator, but it will have to fight to keep this position.

On the mobile app side, Adobe can try to promote the AIR-to-native path, but it's going to be competing with a growing number of "write-once, run-everywhere" companies such as Appcelerator, as well as companies that choose to simply develop natively.

Strata 2012 — The 2012 Strata Conference, being held Feb. 28-March 1 in Santa Clara, Calif., will offer three full days of hands-on data training and information-rich sessions. Strata brings together the people, tools, and technologies you need to make data work.

Save 20% on registration with the code RADAR20

Working toward the one-language-per-developer ratio

Frequent WIR readers will know that I'm no fan of language dilution, the process wherein new languages are developed and promoted with such frequency that software engineering becomes a Tower of Babble. It seems like a necessary step in the developing hubris of an organization that it decides to have the one true language that will make life a programmer's paradise. Google has done this several times, most recently trying to replace JavaScript. Now, the normally staid Eclipse foundation has joined the fray with Xtend.

Extend joins C# in the "looks just like Java, if you squint" language camp. The good news is that as a JVM-based language, it can share libraries with Java, so it's not starting from scratch. New code created in Xtend can be used by Java developers. But still, do we need another pretty-close-to-Java language? I spend my days coding alternately in Java and Objective-C, and the cognitive dissonance set up as I switch back and forth can generate major cranial pain. Is it 'this' or 'self'? Do I send a message with a dot or by putting it inside brackets? It's much easier to switch between languages that share nothing in common because it's the small differences that screw you up. Xtend is going to be another language close enough to one I already know to make me go nuts remembering the deltas between the two.

Because it's the only shape that can't fall into a manhole, that's why!

Work long enough in the industry, and you'll end up interviewing for a company that thinks trivia and brainteasers are a good way to test applicants. Increasingly, companies seem to think that tests and code challenges are the best way to find the "best of the best." Neil McAllister has an interesting essay in InfoWorld questioning if this really leads to the desired outcome.

I tend to agree, somewhat. Tests that require an applicant to pull obscure or advanced knowledge out of his or her head aren't good tests because they are essentially memory exercises. The best "challenge-style" test I ever had was when I applied for a job at ITA, now (ironically) a part of test-junkie Google. They sat me down in front of a system with carte-blanche Internet access and the ability to install any tools I wanted, and to use any language. Then, they presented me with a heuristic challenge: as I remember, it was to find all the possible anagrams of varying lengths you could find in a provided dictionary.

What I liked about this test was that the company seemed interested in my process, rather than my ability to immediately churn out the right answer. I sat with my minder for several hours, refining the code, adding features that he requested — much more like pair programming than a pure test. At the end of the day, they knew how I worked, how I found things I didn't know or remember, and my coding methodology. It was time-intensive, but much more useful, to my mind, than knowing why manhole covers are round.

Got news?

Please send tips and leads here.


July 11 2011

JavaFX 2.0: Making RIA with Java

JavaFXAs far as Rich Internet Applications (RIA) are concerned, the major player for the last decade has been Flash, and its successor Flex. Silverlight has had its supporters as well, and HTML5 is moving the ball forward from AJAX and CSS. And then there's Java.

After a brief stint of popularity, Java applets fell out of style, and even sites that used Java in the back-end rarely used it on the client side. JavaFX, now in its second generation, is an attempt to bring Java back onto the client side, and Jim Weaver is a big fan. Founder of JMentor, Weaver thinks that JavaFX brings a rich programming environment to the client, he'll be talking about that at OSCON later this month. He recently clued us in on why he thinks JavaFX is such a strong contender.

Can you give us a short history and description of JavaFX?

Jim WeaverJim Weaver: JavaFX came out in 2007. It was created by a guy named Chris Oliver, and it was introduced as a way to be able to quickly and intuitively put together rich client Java user interfaces. Developers in general, and the industry in general, rejected JavaFX primarily because it was a new scripting language. They didn't want to learn a language, so it just didn't get the traction that it needed.

After Oracle acquired Sun, they took a different direction with JavaFX. They abandoned JavaFX Script, the scripting language for it, and made JavaFX a set of libraries, APIs and run time. You code it in pure Java or any Java domain-specific language. That's the focus now. The new version just got out of early access and into a very early beta in June, and it's starting to get some traction with developers trying it and using it for smaller applications.

OSCON Java 2011, being held July 25-27 in Portland, Ore., is focused on open source technologies that make up the Java ecosystem. (This event is co-located with OSCON.)

Save 20% on registration with the code OS11RAD

The argument could be made that with Flash/Flex so ubiquitous on browsers now, and HTML5 gathering steam, another RIA platform is redundant.

Jim Weaver: I have nothing bad to say about Flex. I think Flex has been a great rich-client environment, and they've done a great job with deployment of the run times, except for iPhone and iPad.

The reason why I don't use Flex is because it's not Java. It doesn't have the millions of Java classes that are available out there and the richness of the native Java APIs. You find yourself having to use some bridging technologies. So that's why I'm pushing for Java. But there's nothing wrong with Flex. Flex is great.

I do see a lot of advances in HTML5. I think there's a lot of misconceptions and expectations that need to be calibrated around what HTML5 is: rate of adoption, rate of compliance on different browsers, and that kind of thing. Fundamentally, you're still talking about trying to make browsers an application execution platform. You're still working with JavaScript and you're still trying to shoehorn some technologies.

The mix that I'm shooting for would combine HTML5 and rich-client Java in a number of ways: it would be rich-client Java, web-started, that contains JavaFX APIs for its richness on the client, with a scene graph that contains UI controls, effects, animations and transformations. JavaFX has an embedded web browser component that you can use as part of the scene graph, and it's adopting the HTML5 standard.

The other way of doing it would be the exact opposite, where you have a browser and it's got an app that has JavaFX. I don't like that as well because then you depend on the browser for your JVM and your Java execution environment.


June 03 2011

Checking in on HTML5 video

Though HTML5 video can't fully challenge Flash video's dominance just yet, Greg Schechter, web warrior at YouTube and a speaker at Velocity 2011, says HTML5 is headed in a good direction.

In the following interview, Schechter talks about HTML5 video's architectural issues, how mobile provides a great platform but is something of a crap shoot when it comes to bugs, and how at this point video speed is a toss-up between HTML5 and Flash.

What kinds of architectural issues emerge as you incorporate HTML5 video distribution?

GregSchechter.jpgGreg Schechter: The biggest architectural issue we've had to deal with is providing support for the new WebM encoding format. For Flash we only need to have one encoding, H.264 (at least for the most part). For HTML5 we need to support both H.264 and WebM to support all modern browsers. We've had to make changes to streaming and upload architecture to support the different situations the video might be played in. We haven't converted all our videos to WebM yet, but we are actively working on it.

How do you address HTML5 video across platforms, devices and browsers?

Greg Schechter: For the desktop, the issues are not that bad. Once you make sure you have encoding that the browser can support, the video tag works without too many differences. At the moment, the critical features are supported by all the HTML5 video-capable browsers. We're starting to see feature support diverge, with things like a full-screen API and support for the track tag, which will make it a bit more difficult to handle in the changing development environment.

Mobile sometimes feels like a crap shoot. Sometimes we run into problems caused by hardware constraints, such as a device not being able to capture frames of a video to show in a paused state outside of the native player. Other times, it's bugs with the layout engine that don't render as expected. Every now and then we run into a crazy bug that affects phones but not tablets, or it affects tablets but not phones. Fortunately, these bugs don't happen all that often, but they can certainly cause some bad headaches.

Velocity 2011, being held June 14-16 in Santa Clara, Calif., offers the skills and tools you need to master web performance and operations.

Save 20% on registration with the code VEL11RAD

How has HTML5 affected mobile video distribution?

Greg Schechter: Mobile support is one of the best benefits to HTML5 video. Our two biggest markets for mobile video are iOS and Android. iOS doesn't support Flash, and many users haven't installed it on Android. Thus, with HTML5 we're able to easily provide both these platforms with a video viewing experience.

Your Velocity presentation is titled "HTML5, Flash and the Battle for Faster Cat Videos." Is there a clear winner yet?

Greg Schechter: There are a lot of different elements to measure to compare the performance between the two players. Because HTML5 doesn't require a plug-in, it will start up faster. This is great for our embeds because the time until the user sees the video thumbnail is a lot faster. Unfortunately, we haven't seen the same results in how long it takes to play the video — Flash is a lot faster. Some of this has to do with our architecture, but we've also seen inefficiencies in the browsers, which we are hoping will be fixed soon.

A video embedded with YouTube's old embed code

A video embedded with YouTube's HTML5-friendly iframe code

Are you surprised at the adoption pattern for HTML5 video?

Greg Schechter: We're still experimenting with our HTML5 player. It's mostly an opt-in program, so the numbers are pretty low for now. But I have been surprised with people looking for HTML5 support for our embedded player. People have been really excited and eager to use our JavaScript API with our iframe embed on mobile devices, where HTML5 is key. Our Flash player has been doing an excellent job at video distribution for years. Both YouTube and the browser vendors have some work to do in order to get the HTML5 player up to snuff, but once we're there, I'm confident we'll have a great user experience to compete with Flash.

This interview was edited and condensed.


February 01 2011

Can Flash and HTML5 get along?

Flash and HTML5As the HTML5 standard evolves, and the technology becomes more capable, it's natural to start examining the overlap between Flash and the new capabilities of HTML5.

One person with a strong opinion on this subject is Duane Nickull, Adobe's senior technical evangelist. He'll be talking about the new world of HTML5, AJAX and Flash at Web 2.0 Expo, and he gave us a sneak peak at his thoughts on the subject.

To what extent do HTML5 and Flash cover the same ground, and to what extent do they play well together?

Duane Nickull: First, let's clear up a common misperception about HTML5. When many people say or think "HTML5" they really are referring to a set of technologies that includes things like jQuery, AJAX, CSS and even plain old JavaScript. Likewise, Flash is more than just the Flash — *.swf — file format. Flash is a complete platform that has server-side components, authoring tools, protocols, binary formats, supported codecs and even side-channel communication features in server products like Livecycle Data Services and the Flash Media Server.

Most of the time, a Flash-based application deployed to the Internet is done so within an HTML container. It uses JavaScript to invoke and instantiate an instance of the Flash Player browser plugin. One could summarize that HTML and Flash always play nice together, and in fact, Flash relies on HTML.

How is Adobe addressing HTML5?

Duane Nickull: Adobe's strategy is to embrace and develop toolsets for both HTML5 and Flash. HTML5 is an exciting technology and in my opinion, HTML, as a standard, has stagnated for far too long. We are participating in the W3C standards group as well as pushing to bring features into our products as early as possible. At Adobe MAX 2010, we also previewed a prototype technology, conceptually similar to Flash Professional CS5, to show designers and developers how simple and intuitive it could be for them to build interactive animations with HTML.

Developers and architects have to make decisions about which technology suits them best. Let's use forms as an example. In many cases, HTML forms are given preference to Flash-based forms for online experiences, as they load quickly and do not require a plugin. If the architecture calls for offline use, then PDF or AIR applications, often Flash-based, start to make more sense. Adobe doesn't tell developers which technology to use. We deliver multiple choices and allow developers to make their own decisions. Developers would refute such arrogance if anyone demand they always use one technology over the other.

Web 2.0 Expo San Francisco 2011, being held March 28-31, will examine key pieces of the digital economy and the ways you can use important ideas for your own success.

Save 20% on registration with the code WEBSF11RAD

The overlap between these technologies grows as HTML5 is used more, and functions like the video tag are added. There are some real issues, though, with merely pointing a browser at a video source and expecting it to work in all browsers on all devices and bandwidth variations. The Flash platform has a history of delivering a high-quality user experience for video by detecting bandwidth and processing capabilities and then compensating attributes of the video playback to suit that context. This requires server-side components and side protocols to monitor the playback. HTML5 is a markup language, and it may not be able to match the video experience on all devices that Flash Player now delivers unless it adds a comparable server-side option to the equation.

Another consideration is the actual rendering of the video controls and frame. Using Flash Player, the rendering is consistent if developers use something like the standard video control. If you write your own control in HTML and CSS it is possible that it might look different on different browsers. CSS today has issues with rendering across all combinations. You have Opera, Chrome, IE, Safari, Firefox, et al. Most of these run on three to 10 different operating systems, supporting an average of around five multiple concurrent versions of both browser and OS. This means you have a matrix of 5 * 10 * 5 * 5, or around 1,250 variations, which is a fairly large matrix to test CSS against. That's not even the end of it, either. Some people are still using IE6. I have voiced my concerns about this on my blog.

How is the Flash / HTML5 story going to play out in the mobile space?

Duane Nickull: I think it will play out much as the Internet is already playing out. Adobe will give developers the choices to build the way they want to build. The Flash Platform certainly has an appeal for mobile development and the only hitch is that it's not currently running on the iOS platform.

Consumers have a choice, though. Millennial Media recently reported that Android phones in the U.S. accounted for 46% of traffic on its ad network, more than Apple's 32%. Android, which supports Flash on mobile in Android versions 2.2 or higher, has also taken the No. 2 spot in smartphone handsets and is poised to grow even more.

The tablet market is also heating up. Research in Motion (RIM), which will support both HTML5 and Flash Player as Android does, is poised to make a big splash in the tablet market despite Apple's early lead.

Adobe's strategy, again, is to ensure we deliver the tools that give developers choice. We love Flash and we love HTML and its peripheral technologies.

This interview was edited and condensed.


June 18 2010

Four short links: 18 June 2010

  1. Facebook Changes Crawling Policy (for the better) -- they're implementing their crawling policy in robots.txt and not in additional contractual terms. This is in response to Pete Warden pointing out that robots.txt is industry standard and will avoid confusion such as landed him with large lawyer bills. This change came from Bret Taylor, their CTO, who was product manager for Google Maps and gets working sanely with developers. (via Pete Warden)
  2. Law as Source Code (Sean McGrath) -- there's something important coming together in his series of blog posts about law. What we have here are two communities that work with insanely large, complex corpora of text that must be rigorously managed and changed with the utmost care, precision and transparency of intent. Yet, the software community has a much greater set of tools at its disposal to help out.
  3. AppEngineJS -- a port of the Google Appengine Python SDK to JavaScript [...] JavaScript Web applications powered by Google's infrastructure [...] at client and server side.
  4. Axiis -- Flash-based visualization framework.

May 31 2010

Four short links: 31 May 2010

  1. Transparency is Not Enough (danah boyd) -- we need people to not just have access to the data, but have access to the context surrounding the data. A very thoughtful talk from Gov 2.0 Expo about meaningful data release.
  2. Feed6 -- the latest from Rohit Khare is a sort of a "hot or not" for pictures posted to Twitter. Slightly addictive, while somewhat purposeless. Remarkable for how banal the "most popular" pictures are, it reminds me of the way Digg, Reddit, and other such sites trend towards the uninteresting and dissatisfying. Flickr's interestingness still remains one of the high points of user-curated notability. (via rabble on Twitter)
  3. Potential Policy Recommendations to Support the Reinvention of Journalism (PDF) -- FTC staff discussion document that floats a number of policy proposals around journalism: additional IP rights to defend against aggregators like Google News; protection of "hot news" facts; statutory limits to "fair use"; antitrust exemptions for cartel paywalls; and more. Jeff Jarvis hates it, but Alexander Howard found something to love in the proposal that the government "maximize the easy accessibility of government information" to help journalists find and investigate stories more easily. (via Jose Antonio Vargas)
  4. Smokescreen -- a Flash player in Javascript. See Simon Willison's explanation of how it works. Was created by the fantastic Chris Smoak, who was an early Google Maps hacker and built the BusMonster interface to Seattle public transport. (via Simon Willison)

March 15 2010

Why HTML5 is worth your time

The debate over HTML5 vs. Flash is great for comments and page views, but all that chatter obscures the bigger issue: Should developers and designers invest in HTML5?

According to Eric A. Meyer, an author and HTML/CSS expert, the answer is a definitive yes. In the following Q&A, Meyer explains why HTML5, CSS and JavaScript are the "classic three" for developers and designers. He also pushes past the HTML5 vs. Flash bombast to offer a rational and much-needed comparison of the toolsets.

HTML5's feature set

Mac Slocum: How is HTML5 different than HTML as we currently know it?

Eric A. MeyerEric Meyer: It's really the HTML we're all used to plus more elements. But that's the 80/20 answer. HTML5 adds new elements for things like sections of a document and articles, and figures and captions for figures. So it covers things that a lot of us do all the time, like create <div class="figure"> and then <p class="caption"> inside of that to go along with an image. Now there's just an element called "figure" and you insert an image and you have an element after that called "caption."

There's been an attempt to look at what people are doing. What class names are people using over and over again? What structures are they setting up over and over again? Because HTML doesn't have elements that directly address those.

The HTML5 spec also attempts to very precisely and exhaustively describe what browsers should do in pretty much any given circumstance. Older HTML specifications would simply say: "These are the elements. These are the attributes. Here are some basic parsing rules. Here is what you're supposed to do if you encounter an error." HTML5 has these really long algorithms that say: "Do this, then this, then this, then this. And if you hit a problem, here, do this other thing." There's a lot of debate as to whether that's even a good idea. But if the vision that's encoded in those algorithms is brought out -- I'm not saying it will be, but if it is, then browsers will be a lot more interoperable.

But that's the base level answer. As you push further into the more obscure corners, then the answer to "how is HTML5 different?" becomes much more complicated.

MS: Is HTML5 becoming a full-fledged development environment?

EM: I don't see it stepping forward into full-fledged programming. But I do see it pushing HTML forward so that it's a better foundation for web apps. That's one of HTML5's primary goals. There are sections of it that are devoted solely to how to deal with web application environments.

The thing that's most directly applicable to making HTML more web-application friendly is the attempt to include what's known as microdata. That's semantic information and little snippets of data that can be embedded directly into what we think of as pages right now. But these can become the views a web application presents. It's the kind of stuff that we put in cookies now.

But HTML is not getting for loops or switch statements. That's going to stay with JavaScript. In that sense, no, HTML is not becoming a programming language.

What developers and designers need to know about HTML5

MS: What skills do developers need to take full advantage of HTML5?

EM: Developers need to know HTML5. They need to know JavaScript and they need to know CSS. That's the classic three.

MS: How about designers?

EM: Designers need to know mark-up. They need to know HTML5. They need to be able to write CSS and understand web layout. And they need to have at least a decent grasp of what JavaScript does. I don't necessarily insist that everyone who ever touches the web be able to write their own web app by hand, but designers should understand how JavaScript works.

There are a lot of people who call themselves web designers who are really just designers who put their designs on the web. And there's nothing wrong with being just a designer. But they're not necessarily web designers. They're visual designers. There's a difference.

MS: Would you recommend starting with web development skills and then adding Flash and others later?

Yeah. Make that your grounding and then add things to it if you like. You're making a very dangerous bet to not have web tools at your disposal. The developer should be able to do web work. And it's not a bad idea to add Flash to the tool belt.

HTML5 vs. Flash: A rational comparison

MS: Without getting into the "Flash killer" stuff, how does HTML5 compare to Flash?

EM: HTML5 itself and Flash are vastly different. They have different things that they're trying to do. But the HTML5 plus CSS plus JavaScript package is more. I think that's an easier comparison to make to Flash because Flash is supposed to be this total environment. You can put things on the screen and you can script it and you can define interaction. And HTML5-CSS-JavaScript lets you do that as well.

We got to the point a couple of years ago where the HTML-CSS-JavaScript stack can technically do just about anything that the Flash environment makes possible. It's just a lot harder at the moment to do that in HTML5-CSS-JavaScript because Flash has about a decade's head start on authoring environments.

There are a number of people, myself included, who have been observing for a while now that the current web stack feels like Flash did in 1996. Look at the canvas demos, for example. The canvas demos we're seeing now are totally reminiscent of the Flash demos we used to see in the '96 era, where it was like: "Hey, look! I have three circles and you can grab one with a mouse and flick it. And then it bounces around the box and there's physics and collision and animation and they're blobby and woo hoo."

MS: What's your take on plugins? Are they inherently inelegant?

EM: That's been my feeling for a long time. That any plug-in is kind of inelegant and the wrong way to be going about this. And I don't reserve that just for Flash. I really mean any plug-in. The fact that we need plug-ins to play movies has never felt right.

MS: If, for a given application, HTML5 and Flash can provide the same result, why would a developer go with HTML5? What's the motivation?

EM: HTML5 is native to the medium. It's the feeling that if we're going to do web stuff, let's do web stuff. Let's not do Flash stuff that happens to be represented in a web page. So I think that's the philosophical drive.

The technical drive, to a large degree, is that companies don't want to be beholden to somebody else. And doing everything in Flash means that they're effectively beholden to Adobe. With web technologies, the only entity that can reasonably be said to hold the keys to the kingdom is the W3C. And even if the W3C for some reason turned into "evil goatee Spock" tomorrow and said "we want licensing fees," everyone would go, "yeah, no."

HTML5 and mobile applications

MS: Does HTML5 give mobile developers more latitude? Is there benefit in developing applications outside Apple's approval process?

EM: Absolutely. No question. There are some people who have argued that the whole App Store phase is a fad. Granted, a very popular and lucrative and probably long-lived fad, but that it's still a fad.

The argument is that 10 years from now we're going to look back at rebuilding apps for every mobile device and go "What the hell were we thinking?" It's the same way kids who graduate from decent web development programs today don't understand why anyone ever tried to layout a page with tables. I've had conversations with people who literally just can't understand. Even when you explain, "Well, there was no CSS." They're like, "But surely there was something better because that's just awful."

Betting against the web is the sure losing bet of technology. Over the long-term, that's where I see things going.

Note: This interview was condensed and edited.

Tags: flash html5

January 14 2010

Four short links: 14 January 2010

  1. Four Possible Explanations for Google's Big China Move (Ethan Zuckerman) -- I'm staying out of the public commentary on this one, but Ethan's fourth point was wonderfully thought provoking: a Google-backed anticensorship system (perhaps operated in conjunction with some of the smart activists and engineers who’ve targeted censorship in Iran and China?) would be massively more powerful (and threatening!) than the systems we know about today. It's deliciously provocative to ask what the world's strongest tech company could do if it wanted to be actively good, rather than merely "not evil".
  2. Gordon -- An open source Flash™ runtime written in pure JavaScript. (via Hacker News)
  3. Pop Software -- great blog post about this new category of software. The people who are consuming software now are a vast superset of the people who used to do so. At one time, especially on the Mac, we’d see people chose software based upon how well it suited their requirements to get a job done. This new generation of software consumers isn’t like that - they’re less likely to shop around for something rather they shop around for anything. These are people who want to be entertained as much as they want to have their requirements met. [...] Apps are not Applications - they are their own things. They are smaller. They are more fun. Pop software has amazing scale, is hit-driven, is a very hard business for developers, and isn't going away. (via timo on Delicious)
  4. Why Hasn't Scientific Publishing Been Disrupted? -- an analysis of the scientific publishing world: what roles it serves, how some of those roles can be better served by new technology, and which roles are still mired in traditions and performance plans anchored to the old models. As is often the case, people won't move to the new system when the amount they're paid is determined by the old system. (via timoreilly on Twitter)

November 30 2009

Steve Souders: Making Web Sites Faster in the Web 2.0 Age

O'Reilly Velocity Online Conference 2009As much as anything else, a user's impression of a web site has to do with how fast the site loads. But modern Web 2.0 websites aren't your father's Oldsmobile. Chocked full of rich Flash content and massive JavaScript libraries, they present a new set of challenges to engineers trying to maximized the performance of their sites. You need to design your sites to be Fast by Default. That's the theme of the upcoming Velocity Online Conference, co-chaired by Google performance guru Steve Souders. Souders is the author of High Performance Web Sites and Even Faster Web Sites, and spent some time discussing the new world of web site performance with me.

James Turner: There's been an evolution of the whole area of web performance, from the old days when it was all about having a bunch of servers and then doing round robin or just spreading the load out. How is web performance today different than it was, say, ten years ago?

Steve Souders: Well, what's happened in the last five years or so is that Web 2.0 and DHTML and AJAX has really taken off. And that's really been in the last two years. Five years ago, we started seeing a lot of flash and bigger images. So basically what's happened is our web pages have gotten much richer, and that also means heavier. There's more content being downloaded, more bytes. And then in the last two years, with the explosion of Web 2.0, we're seeing not only a lot more bytes being downloaded into web pages, but we're seeing that that involves a lot of complex interaction with JavaScript and CSS. And so whereas maybe five or ten years ago, the main focus was to build back-end architectures that would support these websites, we're seeing today that we need a lot more focus on the front-end architecture of our websites and web applications.

So that's where Velocity comes in, and my work comes in. Whereas ten or twenty years ago, you had people looking at collecting and evangelizing best practices for back-end architectures like databases and web servers, Velocity and my work is about identifying and evangelizing best practices for building really fast high-performance front-end architectures.

James Turner: I know, as someone who's been doing AJAX development, AJAX is a very different kind of paradigm for how you're interacting with the server. It's a lot more chatty. Are the current generations of web servers really designed for that kind of interaction?

Steve Souders: I think that the chattiness of AJAX applications isn't really the issue with regard to performance. I mean, anything can become an issue, but looking across the top 1,000 websites in the world, that's not the issue. The issue is that these web applications that do AJAX require a lot of JavaScript to set up that framework on the client, inside the browser. And to set that up, to download all of that JavaScript and parse it and execute it just takes a lot of time. A user is downloading complex photos or mail or calendaring application, and before they've even done any chatty AJAX request, they're just waiting for the application to actually load and start up. That's the frustrating period, you just want to get in and start working on your slides or reading your mail, and you're waiting for this start up to happen. Typically, once these AJAX frameworks have loaded, the AJAX work that we're doing in the background is not that big of a problem either from a back-end perspective or from the client side perspective.

James Turner: One of the things we see a lot these days is people using libraries like YUI or Google's libraries or JQuery . They have compressed versions, but they're still pretty large. To what extent do you think there's a need to really go in and pick and choose out of those libraries?

steve-souders-velocity.jpg Steve Souders: Well, myself personally, I do that frequently because I only need usually one small feature, like I need a carousel or I need a drop-down menu or something like that. And I'll go to the work of pulling out just the code that I need. But I'm working small website projects. If you're building a whole web application, you're probably using many parts of these JavaScript frameworks. There still might be some benefit in pulling out just the pieces that you need. But that's extra work. And when you need to upgrade, that's the likelihood of introducing bugs or other problems. So certainly, I wouldn't avoid doing that. It should be evaluated, pulling out just the JavaScript that you need from the frameworks so long as the licensing even supports that.

But something else that helps address that problem is the Google AJAX Libraries API. This is where Google is actually hosting versions of JQuery and Dojo and YUI and Google's Closure JavaScript framework and Scriptactulous and EXT and others. What happens is you can have multiple websites that don't have any interaction with each other, and, but they both might be using JQuery 1.3.2. And if they're both downloading that library from the Google AJAX Libraries API, then the URL is exactly the same. So a user that visits multiple of these websites only has to download that JavaScript once during their entire cache session. That further mitigates the need or motivation or benefit of pulling out just the parts that you need.

At first, I didn't think there would be that much of a critical mass around these people that would adopt the Google AJAX Library CDN and the actual version numbers of these JavaScript frameworks, but it's actually taken off really well, a lot of websites are using them. Users are actually getting this critical mass benefit where when they go to some website,, that's using JQuery, they already have that in their cache from a visit they made a previous day to a different website. So I think in general, I would recommend to developers that they not change the JavaScript frameworks they're using. And if they're using a framework that's hosted on Google, download it from there. It's hosted on Google's infrastructure, so it's going to be fast, reliable, and users will actually get the benefit of having a greater probability of the framework being in their cache, because multiple websites are taking advantage of loading it from there.

James Turner: I have to put my security hat on for a second and ask, when you get into a situation like that, the flag that comes up for me is if someone managed, by some kind of an injection fake, delivery a version of a library that had vulnerabilities so that it appeared to be coming from Google, you could get into a situation where someone would be using a poison library. Do you think that's at all a realistic concern?

Steve Souders: Well, I think it depends on who's doing that. I work at Google so I don't want to come off as sounding like a fan boy who's only going to say great things about what Google is doing. I'm as cautious as the next person with what passwords I use and what information I give to any web company. But when it comes to something like this, I've built stuff that's running on Google App Engine or Amazon AWS. It's always possible that these big companies, these big web hosting providers are going to go down. But there's probably a greater chance that my website is going to go down than Google or Amazon. And the same thing with security. There's probably a greater chance that my website is going to be hacked than Google or Amazon. So I think it is a possibility. But I think the odds are pretty small of that happening. And that would not be a concern that would stop me from taking advantage of these services because of the performance benefits I get from them.

James Turner: Staying a little bit on security, there's certainly been more of an emphasis over the last, pick your unit of years, about making sure that data stays secure. You see things like Open ID now and everything pretty much is SSH'd. How much of a balance do you have to keep between performance and security or can they work in concert?

Steve Souders: I don't think there is that much tension between performance and security. The things that are making websites slow are not being done in a slow way because people are striving to have greater security. In most of the places where improvement could be made, the improved way, the higher performance way of doing things, doesn't change your security exposure to any degree.

There are some situations where protecting the users' data could make a website slower. For example, suppose I'm a mail application and I want to not cache the user's address book. You want to protect the user's data. That's a higher priority than performance. And so you make that address book response non-cacheable. Now that will make the website slower, the web mail application slower the next time the user goes there, but that one request for the user's inbox and the user's address book, those small number of requests are insignificant compared to all of the other JavaScript and CSS and images that are being downloaded. So whether you cache that or not, whether you load it over SSL or not, that is not what's making websites slower. The things that are making websites slower are large amounts of JavaScript, much of which is not used in the initial loading of the page, images that are not being optimized and these other performance best practices that are being evangelized by tools like YSlow and Page Speed.

James Turner: You've been focusing a lot on the front-end. I have to say as someone who works largely on the back-end, one of the trends I've seen is more and more tiers being layered on, of more and more complexity. Maybe not now, but certainly a few years ago, everything was going to be SOAP over web services with Enterprise Service Buses and all of this very complex multi-tier architecture. Wasn't that just latency waiting to happen there?

Steve Souders: Well, if you look at most websites, you'll see that for almost all websites, less than 10 to 20 percent of the page load time is spent getting the HTML document. And that's largely where this back-end potential for latency lies that you're talking about. It lies behind generating that HTML document. That HTML document might generate a page that has a few more hits on the back-end for some AJAX responses or some dynamically generated JavaScript, but by and large, that's where you're going to have the biggest latency impact from the back-end, from these tiers that you've described, it's generating the HTML document. And yet we see across almost all websites that the HTML document, not just the generation of it, but the request going up to the web server and the response coming back, all of that is less than 10 to 20 percent of the page load time. So it's certainly not the long pole in the tent. And, in fact, if you could drop the HTML document time to zero, most users wouldn't notice. It's that front-end part that is the long pole in the tent.

That's not true of all websites. It's probably true of 95 percent of the websites out there. There are certainly a number of websites where the back-end is taking a long time. It's taking 30 to 50 percent of the overall page load time. The first thing I recommend website owners do is get a handle, get an idea of the overall page load time. And then the second thing I say is break that into two parts: the back-end and the front-end. And if you find that like most websites, your back-end time is less than 10 or 20 percent, then you're correct in focusing on these front-end best practices. If your back-end time is 30 to 50 percent or more, then you should really start on looking at your back-end architecture.

Perhaps there are some latency delays injected there because of multiple tiers or other web services that you're using. But there are even some best practices in that situation. For example, flushing the document early is a situation where if you do have a lot of web service requests that are required to generate your HTML document, you can still send back some of your HTML page to the browser early before you start those slow web service calls and give the user some content and some feedback and start the browser doing some work while you continue on with your other back-end requests in processing.

James Turner: One place that I see a lot of slowdown in pages has nothing to do with the site I'm actually visiting, but a lot of times, it appears the ads being served on the page. What's the state of that right now? It seems like the people who are doing the least to optimize their performance are the ad servers.

Steve Souders: Yeah. Ads being served, third party ads being served inside of web pages, is becoming more of a problem. It's not that it's getting worse; it's that everything else is getting better. When I started this work about five years ago, the percentage of problems that could be associated with ads was pretty small. Maybe 20 percent of the improvements you could make to a page had to do with ads. That's because most websites weren't focusing on these other best practices of spriting and ETags and caching. Well, in the last five years, we've seen a lot of the major websites adopting these front-end performance best practices. So it's not that ads have gotten worse; it's that the actual website content has gotten so much better. Now, of the bad performance practices that you see inside of popular web pages, a much higher percentage, maybe 40 or 50 percent of the problems are introduced because of third party ads.

And it's not too surprising that that's happening for two reasons. One is that it's amazing that this system of serving third party ads works. Here you have two companies that have never spoken to each other. You have two sets of web developers who have never met and never exchanged any plans for how to integrate content. And yet, this third party ad service can serve up content that almost 100 percent of the time loads correctly in some publisher's page. That's just an amazing infrastructure that has worked for as long as it has and it continues to work, especially when you consider all of the cross browser compatibility issues that can arise.

So how is it that we were able to achieve that? Well, it's because we adopted a framework of inserting ads, of creating ads, that's pretty simple. And because it's pretty simple, it's not highly tuned. That's one reason why we shouldn't be too surprised that we see performance issues in third party ads. The other reason is that ad services are not focused on technology. Certainly companies like Yahoo and Google and Microsoft, we're technology companies. We focus on technology. So it's not surprising that our web developers are on the leading edge of adopting these performance best practices. And it's also not surprising that ad services might lag two, three or four years behind where these web technology companies are.

I think that's where we are. We've seen a lot of adoption of these performance best practices in these web companies over the last three years and now it's time for the ad services to catch up. I don't know what the answer is there. It's going to require changing this huge infrastructure for serving third party ads, and that's not something that's easy to do. Certainly we know things that we can do to make ads serve better, to make them faster, to reduce the impact they have. But getting that to propagate across this huge ecosystem of ads is going to take a long time, a lot of evangelism, a lot of monitoring and a lot of organizational changes. It's not something that's going to happen overnight. But hopefully in the next few years, we'll see progress there.

I know in the last two years, the IAB has established a performance working group and has published some guidelines for how to make ads higher performance. I think we'll continue to see progress there. And just as we're seeing with web companies, where companies that have faster web pages are more successful, have greater revenue, reduced operating expenses, the ad services are going to realize that too, that when it comes to ads, faster ads are going to have a competitive advantage. I think, in part, the ecosystem will take care of itself. These ad services will realize that to remain competitive, they need to be fast.

James Turner: Okay. I'm going to wrap up with one last, kind of geeky, question. What is the state-of-the-art in small good-looking images these days?

Steve Souders: Well, when it comes to images, the two experts in the industry are Stoyan Stefanov and Nicole Sullivan. I worked with both of them over in the Yahoo Exceptional Performance Group. And they, in fact, contributed a chapter to my most recent book on optimizing images. So they're really the experts, but I think I can summarize what they would say. If you have small images with a very few number of colors, GIF is probably going to be the optimal format to use. All of these formats are supported across all browsers. In most cases though, PNG is going to be the format to choose, you can choose PNG 8 for images that are less than 255 colors or PNG 24 for images that are over 255 colors. And if you have a very high resolution image, like a photograph, JPEG is still the optimal format. So your question was about small high-quality images. PNG is going to be the format of choice, most likely, for those types of images.

Planning to attend the O'Reilly Velocity Online Conference on December 8, 2009? Register using code velfall09d25 and receive 25% off the registration price!

November 09 2009

The Minds Behind Some of the Most Addictive Games Around

The gaming industry tends to focus on the high end products, first person shooters that crank out a bazillion polygons a seconds and RPGs which spend more time developing the plot in cut scenes than in actual gameplay. But for every person playing Borderlands, there are scores playing casual games like Bejeweled and Zuma. PopCap Games has been at the forefront of casual game development, with a catalog that includes bestselling titles like Peggle and Plants vs Zombies, in addition to the two previously mentioned. I recently had a chance to talk to Jason Kapalka, one of the founders and the creative director of PopCap. We discussed the evolution of PopCap, how the casual gaming industry differs from mainstream gaming, and the challenges of creating games that can be engaging, without being frustrating.

James Turner: Could you start by talking a little bit about your background and how you came to PopCap and what you did before then?

Jason Kapalka: My career in computer games started back in the early '90s, when I was writing for the magazine, Computer Gaming World, doing various reviews and articles. In '95, one of the editors from the magazine left to join an internet dotcom start-up in San Francisco called TEN, the Total Entertainment Network. He invited me to come down there and work there, which I did. And TEN evolved over the dotcom boom and bust cycle, from a very hardcore gaming service into what eventually turned into around 1999. I worked there initially on hardcore games. One day, I was working on Total Annihilation tournaments, and then the next day, someone said, "Hey, design bingo." And I was sort of like, "Oh. Bingo? Okay."

pvz.jpgThat was the beginning of my casual game design career, I guess. And yes, I was there at Pogo. I helped design a lot of the structure for their casual games until around 2000 when I left, and Pogo eventually went on to get bought by Electronic Arts, of course. I left in 2000 and started PopCap with two other guys, Brian Fiete and John Vechey who are these guys from Indiana that I'd met earlier, around '97. They had made an internet action game called ARC that we'd produced on TEN, and we stayed in touch. In 2000, we all thought we wanted to try something different. So we all left our respective companies to start PopCap. As you might remember, 2000 was not the best year for internet companies. So we didn't really realize that the entire industry was collapsing. We had an interesting time initially. Luckily, our ignorance protected us, I guess.

PopCap started from there, just the three of us working out of our apartments. And over time, we'd say, "Well, I guess we need to hire an artist." And I'd say, "Well, I guess we need to hire maybe another guy here to program this stuff." And then eventually, maybe someone should look at the books or whatever, so we'll hire someone to take care of the bookkeeping. And it kept going like that until eventually we thought that maybe we needed an office. And from there, suddenly, we've got nearly 300 employees now in 2009. So it's been an interesting kind of experience. We never really intended PopCap to get anywhere near as big as it has today.

James Turner: How would you describe PopCap's place in the market today?

Jason Kapalka: I guess it's a bit odd. Casual game companies exist in these strange spaces where they're often the developer and the publisher at the same time. And then they also publish stuff with other guys, where they're sort of rivals, but also they're partners. There's a lot of this co-opetition thing going on. PopCap is obviously a developer, and we develop a lot of games. We used to publish other people's games. And we still do indirectly. in that we have SpinTop Games. which is a company we bought a couple of years back. They distribute a lot of other people's games through their site. But primarily, I think we develop and then publish titles. But we primarily focus on publishing our own titles. So we're kind of a self-publisher, I suppose.

James Turner: That's actually something I wanted to ask you about because one of your distribution channels now is Steam, which is another company's portal for their games and others. How do you see that relationship?

Jason Kapalka: Steam's been really good. We work with lots of different portals. Steam is one of many that our typical game would go out on. On Steam, on Real Arcade, Big Fish Games, Yahoo Games, MSN, WildTangent, a whole bunch of smaller channels. So Steam was just one of several. It's been interesting in that it was developed differently than a lot of those other ones. Steam is definitely much more of a hardcore game distribution channel than something like Real Arcade. So initially, when we started on Steam, it was uncertain whether our games were going to really fit in. Initially, a lot of the ones we tried on Steam didn't really work too well for their audience. Hidden object games don't do especially well with Steam users, for example.

The turning point for Steam was probably when we did Peggle Extreme with Valve. I don't know if you remember that. Peggle had just come out, and the guys at Valve really liked it. We were talking and we had some weird ideas. Someone had the odd suggestion to do sort of a miniature-themed version of Peggle that featured all of the Orange Box's characters, the Half-Life, MT Team Fortress guys. It was a really strange idea, because that was a fairly mature violent kind of franchise. And certainly, it didn't seem like the obvious fit for Peggle. But, on the other hand, we thought, "Well, what the heck? We can try it and it's only going to go on Steam anyway so it's not like it'll offend the soccer moms necessarily." So we tried that out, and it went up. And we were all kinds of nervous because we didn't know -- it had launched initially as a free download with the Orange Box. And even though it didn't cost people anything, we were still kind of wondering if there was going to be this big backlash from the hardcore community about, "What the hell is this cheap little pinball thing doing in the middle of my Orange Box product."

But actually, the response was really good. I mean, the Orange Box guys all really liked Peggle a lot. And ultimately, that led them to go and seek out and buy the regular versions of Peggle which made Peggle suddenly this fairly big success on Steam. Which a month or two ago, before that, didn't seem very likely that this game with unicorns and rainbows would be selling well on Steam. So after that, that sort of seemed to kind of be -- it sort of opened the floodgates a little bit. And now a variety of our games do very well on Steam. Obviously, Plants Vs Zombies was the last one that had quite a hit there. Not everything. There's still some of our games that are clearly more casual and that don't particularly work well on Steam. But the ones that do work there seem to really work well.

James Turner: There seems to be a fairly different expectation level for casual games in terms of graphics and such. Do you think that's a natural result of how they're produced and what they're intended for? Or could you see something like Plants Vs Zombies but with the graphics levels of a Half-Life?

Jason Kapalka: It's certainly possible. I mean in some cases, we're not intentionally trying to make the games low fidelity. We try to do the best art direction we can. Although the usual contradiction, or decision to be made, there is we also want to make games as accessible as possible. So we want Plants Vs Zombies to play on every crummy netbook and seven-year-old computer your mom has and all of these types of things. And so that tends to mean that we try to work and have good art, but usually make the technical requirements very modest. We've been working at making things that can scale well so that on a good computer, you'll get a really nice experience and it'll still scale down to play on a lower-end computer. But that can be challenging in itself. So usually, we err on the side of not worrying about the graphics being too high-end because our experience is showing that a good game with not very fancy graphics can sell very well, like Plants Vs Zombies. And I think that game has good graphics, but it's definitely limited. It's only got 800X600 resolution and so forth. But on the other hand, we've seen plenty of games in the casual space that have really good graphics and they sell very poorly if they're not a fun game. So accessibility and fun definitely, for us, end up being a first priority over graphics. And especially 3-D or technically impressive graphics versus just good art direction.

James Turner: You would think Nethack and Rogue would be the ultimate proof that you can have good game play without good graphics.

Jason Kapalka: Sure, I love Roguelike games. We have lots of Nethack fans over at PopCap, which seems a bit weird in that they're obviously not very casual in many regards. But yeah, they're good exemplars of that principle that graphics are not as important as game play.

James Turner: In a lot of your games, and especially games like Peggle and Zuma, the game play, to put it mildly, is pretty simple in terms of what the user can do. A lot of times, it's just a mouse click or two mouse clicks. How can you take what is fairly simple game play and keep it engaging so that people want to play it for hour after hour?

Jason Kapalka: Typically, the hard part is keeping it simple to begin with. Usually the problem is is that a lot of time, games become increasingly more complex as you work on them. And it's hard to resist that temptation and keep things simple. With Peggle, certainly one thing that everyone asked for was everyone wanted to have some sort of control over the ball once they'd launched it. So they all thought, "I shoot the ball and then I can't do anything. I just sit there and watch it bounce down. Why can't I have bumpers or a laser beam or something that I can do?" And on the surface, there's nothing inherently wrong with that request. But when you do things like that, suddenly it changes the game. And so the simplicity goes away, and it's no longer as compelling. It's kind of like bowling. If you can control the ball after you throw it in bowling, that doesn't necessarily make it a better game. Or golf. If you had a game of golf where you could change the direction of the ball after you shoot it, again, it doesn't necessarily make it better.

I think with computer game players, often they want all of this control, but I think a lot of classic games actually work well because they limit the amount of control you have. You have to really focus on these clear, specific decisions. And that's a very engaging thing to do. I don't think games like pool or golf will be going away any time soon, and they have fairly simple mechanics at the base of them. You're calculating angles and trajectories. And so that's the case of something like Peggle. It's a similar game. You're calculating angles and trajectories and then making one single decision. But I think that simplicity doesn't mean that it lacks appeal.

James Turner: This next question, keep in mind, is coming from a guy who's now spent three weeks trying to get through the last level of Zuma's Revenge. How do you decide the balance between too easy and too frustrating?

Jason Kapalka: That is quite hard. Obviously, I think I once said that no casual game has ever failed for being too easy. But that's not entirely true. I mean a game that is too easy, people don't perceive it as being too easy; they just perceive it as being boring. And so you certainly don't want to have a game that's boring. At the same time, it's much, much easier to fall into the trap of making a casual game too hard. That's certainly one of the hallmarks of computer game design is to make them very challenging because as a game designer and hardcore game player, that's sort of what you're used to. A lot of the DNA of video games comes from things like the arcade where they were very pure games of skill that they were intended to get very hard very quickly. That's some evolutionary development that's not really relevant in a lot of games today, and especially not in casual games, but it's kind of hard to get out of the habit of that. So with that in mind, trying to figure out how to balance things to be the right level of difficulty is quite challenging.

Sometimes people have a thing where you can select easy, medium or hard. We don't like doing that at PopCap. By and large, the problem I always have with that is it's really hard to calibrate what that actually means because obviously, easy, medium or hard are going to mean different things for different games and for different people. And so one game's easy might be ridiculously difficult on another one. And typically, you're asked to decide that at the beginning of the game when you don't actually know. So I'll start up a game of whatever, whether it's Halo or Ninja Gaiden and decide "Do I want normal or do I want easy? Do I want hard?" In various cases, it could be any of those things and you don't have any good way of knowing until you've actually played the game.

So I don't like having those choosable difficulty settings which means you need to have a game that has one degree of difficulty and that people can adapt to or it adapts to them as they go along. That was a big challenge of Zuma, to try to arrange the levels and so on in such a way that they provide an interesting scale of challenge going upwards without ever getting too insanely difficult. Although, as you pointed out, the later levels of Zuma can get quite hard. Zuma's Revenge is a bit easier than the original Zuma. The original Zuma was quite punishing in many ways. And Zuma's Revenge has gotten a little more forgiving than that. But we figured that it's okay on the later levels if it becomes difficult because by the time someone gets to level 60 in Zuma's Revenge, we assume that they've got the hang of the game and are enjoying the basic game play. Whereas if someone starts at the first level of a game like a Ninja Gaiden type experience and gets his ass kicked repeatedly, that's the sort of thing that may discourage them from continuing to try it at all.

James Turner: I'm going to go off interview for a second here and say the only problem with that is that almost all of the bonus play in Zuma's Revenge is locked to getting through the whole game.

Jason Kapalka: Yeah, and that's something that we've thought about and is actually on our list of things we would probably try to address if we have another Zuma sequel. If you ever see a third Zuma game, we'll definitely try to make some of that content more accessible before people complete the game.

James Turner: The other way that sometimes difficulty is addressed is through cheat codes. And it seems like you've gone out of your way not to have any of that backdoor stuff. Was that a conscious decision?

Jason Kapalka: Yeah. Actually, there's a few Easter eggs and so forth we have in the games, but it really seems the opposite of casual to have these kinds of codes that you need to have the secret hidden knowledge, whether it's digging through the internet or magazines to find these special codes. It's the opposite of making the game accessible, by making one that you have to discover this secret information in order to play effectively. I think it's kind of fun, but only in the context of games where you expect the audience to be really so invested in the game that they're going to kind of go outside of it and seek out that kind of extra information, which is quite common in MMOs and other hardcore games.

James Turner: Is it easier or harder to do sequels to a casual game? Does the lack of a complex storyline make it more difficult in some ways?

Jason Kapalka: Obviously, I haven't had to make Uncharted 2 or anything like that so I couldn't say for sure about the challenges of dealing with a 300 person team. But the challenge that we find for things like Bejeweled 2 or Zuma's Revenge is that you have a very simple structure, and it's challenging to improve that without changing it. The problem I always had is the one that I saw with a lot of Tetris versions. They've been making versions of Tetris for years. And you see a new version of Tetris come up for a new system. You pick it up and check it out. And often, they'd have some new twist on it that once you played it was not very good. And you switched back to playing basic Tetris as soon as you could because whatever new gizmos they threw in there just didn't actually make the game of Tetris any more fun. It made it different, but not more fun.

So when we did Bejeweled 2 or Zuma's Revenge, my first priority was not to make the game less fun. For the sake of making it different so you can say, "Zuma's Revenge has this many different things in it," that helps with your bullet list of stuff if you're trying to sell it. But once you start playing it, we found a lot of the stuff we tried initially -- we put in a lot of things. We put lots of extra power ups in there and a bunch of different kinds of levels and different boss monsters and a whole bunch of stuff, mini games. You could sort of play Space Invaders type mini games with a frog shooting at tiki invaders and so forth. But none of them actually made the game any more fun. It was one of those things where the mini games, for example, you kind of felt more like you were playing Tetris and suddenly, you were forced to play a round of Bejeweled in the middle of it. It didn't make sense. If you're playing Zuma, most people kind of want to play Zuma. They don't want to be interrupted with some random other type of game play. Some of the power-ups, again, we had some extra ones in there that they were different; they just didn't add a lot to the game play and didn't make it any more fun.

So it can be challenging to add stuff and modify a game that has a lot of fans and that is very simple because it's not easy to change that without breaking it. It's like trying to make Chess 2. Many people have made up all sorts of different variant rules for chess, but I don't think too many people would claim that they had improved chess in any universal way. But in a sense, we feel like our job is to try and improve chess, some sort of game that's very simple. That's, to some extent, classic in that it's been out for a while and is loved in its current form by a lot of people. And so you don't want to mess it up just for the sake of saying you changed some stuff and made a sequel that was different.

James Turner: I'm going to morph together a couple of questions that came out of our editors because some of them were similar, and they all were on a theme. So I'm just going to read them all and then you can figure out how to amalgamize them. The first one was: Can you describe your development platform including frameworks and programming languages used and how that relates to target customer platforms? Someone else asked: How do you manage development for games that need to run on multiple platforms? Is that changing with the popularity of mobile platforms like iPhone, Android and Pre? What about mobile platforms like netbooks and Chrome OS? And then someone asked if you were still planning to develop for Web OS?

Jason Kapalka: Okay. Well, our usual platform we develop on is typically for PC and using C++ as the programming language. For a fair number of years now, that's been our default. So when a game is started, that's typically the way we develop it. And later on, we call that our reference build, if we do that. Typically, we'll figure out where to port to after that. And some of the ports are somewhat easy and can involve a lot of the same C++ code. If you're doing a port to XBox, for example.

Other times, if it's Flash, for example, or some Java or Brew mobile handset, it ends up being a fairly major rewrite. We don't have a magic button that ports Peggle onto every different platform available. Sometimes you just have to do it the hard way and do a lot of rewriting of the code and revising the graphics and layout in UI and all of that stuff. So we definitely think it's important to do other platforms, but we certainly feel like you have to take a lot of care to make sure that the game works properly on whatever that platform is. So we do spend a lot of time and effort on ports. I guess we think of them less as a straightforward port than as an adaptation because the challenges of doing Bejeweled on the iPhone, for example, are significantly different than doing it on XBox or some other kind of device.

James Turner: Mobile like netbooks and Chrome OS.

Jason Kapalka: We definitely are trying to keep netbooks in mind when we do games, so that even if we have a game like Zuma's Revenge which has some high-res options, it'll still scale down and run on a typical netbook. And that's unlikely to change. We certainly are well aware that a lot of our audience has lower-end computers. So in a sense, netbooks don't cause us any problems because we were already making games that played on that kind of computer. So we don't really have to do anything extra special to make our games work on a netbook.

James Turner: I was just going to say that I can tell you that I think your Mac port doesn't like running on Hackintoshes because I tried using Zuma's Revenge on a Hackintosh Del 10V and I think you probably didn't optimize your Mac version as much as some of the other ones.

Jason Kapalka: It may be true. Our Mac versions -- definitely our Mac ports, we've had some troubles with those over the years. And we don't yet have 100 percent reliable system for doing our Mac releases at the same time as our PC ones. So yeah, I wouldn't be too shocked to see that there were some issues with the Mac version being not quite as efficient as the PC one. I'm sorry to hear it, but I'm not entirely surprised. We're working to try and get out Mac support to be a lot better than it is currently.

James Turner: The iPhone, obviously, has had a lot of good and bad press about the App Store and how well you can actually make money on that. What's your experience been and how do you think it's going to go with the other platforms like the Android and Pre?

Jason Kapalka: Well, we've been doing pretty well on the iPhone. Bejeweled has, I think, been pretty consistently in the top ten or twenty since launch. And Peggle's done well. And Bookworm's done pretty good. So we've done okay with it. It'd definitely an interesting and challenging platform in that the sheer number of apps out there means that unless you have some way of standing out from that crowd, there's a very high risk with it. I mean, if you're at EA and you have the ability to get big brands out there, or if you're like PopCap where you have a couple of games like Bejeweled that people recognize and will seek out, you have an advantage there. But if you're a brand new developer working on an iPhone game, it's a little scary. One hears about the stories of the guy who wrote a game in his spare time for two months and then put it up on the iPhone store and made $250,000 and quits his day job and all of that. But there's a lot of stories that don't end like that in the same way when you hear about guys going to Vegas and betting their last 20 bucks on a slot machine and getting rich. That does happen, but it's not necessarily a typical story. And it's easy to overlook the risks when you only hear the sort of success stories.

So I think the iPhone is a really cool platform. I think it's a risky one, even for small developers. And I think for large developers, they've already started to realize that it's hard to justify a large development budget for an iPhone game. So they might do it as a marketing tie-in with another game or occasionally if they have a very casual, friendly title like EA with Scrabble. But, for example, right now, not too many people are going to think about investing $1 million making an iPhone game because the risks are just way too high that you'll never make any of that money back. That may change in the future with Android and other platforms that are similar to iPhone, if they start having more touch screen App Store type devices. That might suddenly multiply the potential audience for some of these games by a large amount. I mean the iPhone is cool, but compared to other mobile phones, it's really still owned by a small percentage of people. That might change. In a year or two, you might see iPhone-like devices in a lot of people's hands and if the UI and the App Store experience are similar to the iPhone that might have a huge impact on the way games work. Suddenly, you may find that audience not just growing by a small amount, but doubling, tripping, quadrupling overnight if some new phones in that category become popular.

James Turner: So I have a question from Tim O'Reilly. He wants to know, how do you go about getting new customers? And he says, "Be specific."

Jason Kapalka: How do I go about getting new customers? Well, I'm going to mention two things. One is the not very exciting answer, which is we do what a lot of people do in the casual game space do, you do search engine marketing. That's the most common way on the web to drive people to download games from a casual game site, search engine marketing largely through Google where you buy keywords for various things and people search and blah, blah, blah. You pay a certain amount and they click through. And it's fairly mechanical now because we have metrics to know if this many people download the game, you'll sell this many on average and so forth. So that's kind of the non-interesting way that we get new customers.

The more interesting ways -- well, one example would be Facebook. We've been looking at social networking games for a while. And there've been some interesting things going around there, but we weren't too sure if it was a good idea for us to get into it. It wasn't really our forte. But at the same time, it was a very different kind of crowd. A very different space for us to try something with. So that was the idea behind Bejeweled Blitz, to get into a completely different market than the ones we were in at the time. And sure enough, it has done quite well on Facebook in terms of getting Bejeweled out in front of people who otherwise have not maybe seen Bejeweled very much. And it is a very different crowd on Facebook. The players there are not the types who -- most of them don't play very many games at all. So even by the standards of casual games, they're not the type who even download a game. They don't do any games whatsoever. So that's been a way of expanding our user base to a whole different crowd.

James Turner: One of the ways that you market your games is through one of our editors called teaser apps. What's your conversion rate like on those? Is it an effective way of marketing the games?

Jason Kapalka: If he means the web sort of Flash games and so on on the web, yeah, that is pretty effective. It's less effective than it was when we started about eight or nine years ago when that was, by-and-large, the primary way that you drove people to get interested in games. There would be a flash game on some website or, at that time, a Java game. The player would play a bit of Bejeweled or whatever it was, and then there would be some sort of ad saying, "If you want the deluxe experience, download Bejeweled Deluxe." And then they'd download that, and then they would hopefully buy that. It's less important nowadays. More people are willing to download a game directly, and fewer people feel the need to play the web game first before doing that.

Also, there are a lot of flash games out there that don't have any sort of downloadable component. So people who are playing a lot of flash games are not always in the market for downloadable stuff either. That said, it is still useful. And the conversion rates, they vary a lot for different types of things. Once someone downloads a game, the typical conversion rates are usually in the range of one to five percent. So if you can get somebody to download a copy of Peggle, for example, the typical conversion rates are in the one to five percent range that those people will actually end up buying it.

James Turner: You've mentioned Flash a couple of times. There are some players out there who are pure Flash players, like Armor. Do you see them as a serious competitor to what you're doing. Or are you seeing the same thing as what newspapers are going through, if people are giving it away, how do you make money at it?

Jason Kapalka: I don't think, as far as we've seen anyway, the pure Flash game guys don't really seem to be competing for the same audience that we are. Sites like Miniclip and so on, they do okay with their own business model. It doesn't seem to be crossing over with ours. The problem with developing Flash games for those kinds of sites is that it can be very difficult to turn a profit on them because there's so many Flash games out there. So a site like Miniclip or some of the other ones like that, they pay a pretty small amount of money for a Flash game, between maybe $500 to $5,000 basically, and that's it in most cases. So if you're a Flash developer, that's a pretty small amount of money, unless you're making the game in one or two days.

There are few larger outfits, like Armor Games that you pointed out, that do actually produce games of a higher level of polish and so forth. As for how they make money, I don't know. It's a good question for them actually. I'm kind of curious. I suspect it's a fairly tough business right now because of the massive commodification of Flash games. And so I definitely have heard from a lot of Flash game developers who, despite turning out lots and lots of games all of the time, like some of them are doing a game a day or whatever, they still have a hard time making ends meet just because the prices and so on are just not good for the pure Flash plays.

James Turner: How international is your development effort? And how do you manage it technically and logistically?

Jason Kapalka: Oh, international? Well, we have a development office in Dublin, in Ireland, of about 40 people. And they handle the bulk of our internationalization. So we take it fairly seriously. It's work. It takes time and money to do a decent job with it. The majority of our games, we try to end up eventually internationalizing. Usually there's some kind of decisions. There's EFIGS, which is English, French, Italian, German, Spanish. And that's the basic level for doing European coverage. Beyond that, the typical next steps would be to maybe do some of the Asian languages, Japanese, Korean and Chinese. And we do that as well. We have an office in Shanghai, and they do some of that. Those markets are a little more challenging right now. Some of the reasons are that that Japan is very much a console market and has not got into PC, downloadable stuff very much. China, on the other hand, has big problems with piracy. There's just a lot of piracy out there. And Korea obviously has a lot of MMO kind of focus. So casual games are challenging to get done over there. But yeah, we're trying our best to have a global reach for all of our games.

James Turner: That's a good answer. But I was actually asking do you have international developers? Or is it pretty much all done out of one area?

Jason Kapalka: Yeah, the majority of our developers are all in the US. I mean we do have some developers in Ireland and Shanghai. But in terms of the games that you'd be familiar with now, the majority of them have been developed in North America, either in Seattle or in some cases in Chicago or Vancouver or San Francisco.

James Turner: What these days would be the career path for someone who wants to get into game development?

Jason Kapalka: Well, there's a variety of different paths. There are a number of schools that have some kind of game development programs now. I don't know too much about them. And although I think some of them are very interesting, they're certainly not a requirement. Certainly at PopCap, we don't specifically look for anybody with a game design school background to hire. In many cases nowadays, the best way to get into the game industry is just to do it yourself. The barriers to entry are not what they might've been even five or ten years ago. If you want to make a game now, as I said, you can make a Flash game easily enough yourself. You may not make a lot of money with it, but you can certainly produce it and get it out there in front of people easily enough. And in many ways, the experience of just actually making games is more valuable than any amount of training or books that you can read.

So for someone who wants to get in the gaming industry right now, my personal advice would be to just do it. And whether that means a Flash game or yeah, there's lots of student collectives or just independent guys making a variety of things. It's entirely possible to just make a game. You don't have to go to school for it. You can do the traditional path like ten years ago, get a job as a QA guy at Electronic Arts or Activision or something like that and then work your way up. And that certainly can work. Or go to school for programming or art and then get an entry level job at a big developer. And those methods are still entirely valid. But if you want to get into game design and the creative side of things, I think you can actually just go ahead and do it now which was something that ten years ago was a lot harder to do because there just weren't as many venues for getting your work out there.

James Turner: So two fan boy questions to end things. First of all, are we going to see Plants Vs Zombies 2?

Jason Kapalka: I don't know. We'll see. I'd like to see it myself. We have the same challenge with that as we do with some of our other games in that the guy who made Plants Vs Zombies, George Fan, is hard at work on another game. And so it's a tough one in that we like his new game. We'd like him to work on that. We'd certainly like a Plants Vs Zombies Two as well as that. But it's challenging in that no one besides George would really do as good of a job on Plants Vs Zombies. So we don't necessarily want to just hand it off to a B team and produce something that's not as good. So it's a challenge. I'd like to see it happen, but we'll see what we can do.

James Turner: And finally, do the words in Zuma actually mean anything?

Jason Kapalka: The words, the various chants and so forth?

James Turner: Yeah.

Jason Kapalka: Yes, actually, they do mean something. The chants in the original Zuma are -- well, they're mangled Aztec. So as much as people know of what Aztecs actually talked like, the words in there are very badly grammaticalized versions of that. I think some of the things say stuff like, "Too bad little frog," when you die and so on. And in the second one, Zuma's Revenge, there is actually, again, a very badly mangled version of the Easter Island dialect, which is in existence still and known by Easter Islanders to some extent. So yes, it's possible some people out there in Easter Island, if they played Zuma's Revenge, might recognize a few of the phrases.

James Turner: All right. Well, thank you so much for taking the time to talk to us.

Older posts are this way If this message doesn't go away, click anywhere on the page to continue loading posts.
Could not load more posts
Maybe Soup is currently being updated? I'll try again automatically in a few seconds...
Just a second, loading more posts...
You've reached the end.
No Soup for you

Don't be the product, buy the product!

YES, I want to SOUP ●UP for ...