Tag Archives: flash

Kevin Lynch at Apple

John Gruber has a series of posts questioning Apple’s judgement in hiring Kevin Lynch. This one best sums it up:

“I get that the guy worked for Adobe and had to play for the home team, but as CTO he backed a dying technology for years too long. In 2007 when the iPhone shipped Flash-free, that was one thing. But for Adobe to still be backing the Flash horse in 2010 when the iPad came out — they just looked silly.”

All of that is true. But instead of reflecting poor judgement, I think Kevin Lynch joining Apple could be good news in what it says about Apple. They didn’t hire him blindly. Apple knows what Kevin has been working on, knows what he’s said in public, and at this moment probably knows much better than we do what it was like to be at Adobe those last few years. For all we know Apple cares more about his work on Creative Cloud than Flash.

Kevin also has a rich history that is closely tied with the Mac. He worked as a developer on FrameMaker. He worked at General Magic alongside old-school Apple engineers. He worked at Macromedia when they started building web tools.

I heard him speak much later at SXSW in 2002, for a joint presentation he gave with Jeffrey Veen. At the time I disagreed with Kevin’s vision for Flash and the web, but the SXSW talk was interesting enough that I referenced it afterwards and again later. Kevin was so good that he somehow demonstrated he got the web even as he pitched a product that was increasingly at odds with it.

Was he wrong about Flash? Yes. But I choose to view his move to Apple as an indication that he was at the wrong company more than that he was completely wrong-headed. Maybe it was time for something new, a course correction back to the earlier part of his career. Skepticism about this hire is fine, but to treat him as an outsider is to forget the other great things he’s worked on. Once you’ve built Mac software, no matter how long ago, you’ll always be one of us.

I hope Apple sees it that way too. Because if Apple is confident of anything, it’s that they can’t get stuck in one old way of thinking, can’t discount good people because of one unforgivable bad idea. That Apple is able to brush aside the Flash debate as yesterday’s news — even accept as a VP someone who was at the heart of that debate, and on the wrong side — shows to me that they’re only looking forward.

Wii Transfer 2.7

I finally took the time to give “Wii Transfer”:http://www.riverfold.com/software/wiitransfer/ some much-needed attention, releasing version 2.7 of the application tonight. It’s got the usual bug fixes and some small visual improvements, but the most important change is better video streaming. The biggest mistake I ever made with Wii Transfer was to buy an Apple TV instead of forcing myself to use my own application.

For this release, I sat down with Wii Transfer and a ripped copy of Star Trek, and I just watched it over and over, experimenting with different Flash Video conversion settings and tweaking networking code. I wasn’t going to release this until I could watch a 2-hour movie without any rebuffering. The quality is never going to be as good as a console or set-top box with dedicated video streaming features — this is Flash on the Wii we are talking about — but I’m happy with what I came up with.

Wii Transfer is still only $19, and version 2.7 is a free upgrade for any customer who ever bought the application going back to 1.0 over three years ago. Also an important reminder: all sales go to charity starting tomorrow, January 20th, as part of “Indie Relief”:http://www.indierelief.com/.

FLV metadata performance

One of worst-kept secrets of “Wii Transfer”:http://www.riverfold.com/software/wiitransfer/ is that the movie playback is not as good as what you might see on an Apple TV, Xbox 360, or PS3. I do my best to improve the quality with every release, but let’s face it: while the Wii is perfectly capable of playing fullscreen video, it stumbles when put to that task inside the Opera web browser through Flash.

In the upcoming version 2.6, I’ve added the ability to skip directly to any part of a playing movie by clicking on the timeline with the Wii remote. It was frustrating not to be able to do that in previous versions and made it difficult to watch or fast-forward through long movies.

The way many Flash movie players handle skipping is by inserting metadata into the FLV file that contains a map between seconds in the timeline and file positions for the keyframes, and that’s the way Wii Transfer works as well. Unfortunately this requires rewriting the entire FLV file when post-processing movies. (“Ian Baird”:http://blog.skorpiostech.com/ suggested a future optimization would be to store the metadata separately and redo the player to send seconds instead of file offsets to the server.) I was initially using the open source flvtool2.rb to achieve this, but it was extremely slow, so I rewrote it in Objective-C. (Not a port. The Objective-C version was written from scratch and is significantly shorter than the Ruby version in terms of lines of code. It does a little bit less, but it’s optimized for exactly what Wii Transfer needs.)

This chart shows the performance improvements when processing a couple large movie files. Measured in seconds, so shorter bars are better.

FLV chart

The other good thing that came out of all this work is that I can now look at a FLV file in a hex editor and not be totally confused. “Hex Fiend”:http://ridiculousfish.com/hexfiend/ was one of the best ways to debug what my code was doing when it failed.

Holiday hacking on Wii Transfer 2.0

I got sick (the flu?) shortly after Christmas, but nevertheless managed to sneak in some coding on Wii Transfer 2.0, which I hope to release this weekend. The big new feature for 2.0 is music and picture sharing. Essentially, there is a web server built into Wii Transfer. You can use the Wii’s Opera web browser to connect directly to your Mac running Wii Transfer and pull up MP3s or iPhoto albums. I’ve licensed “Jeroen Wijering’s Flash-based tools”:http://www.jeroenwijering.com/ for listening to MP3s and browsing photos. The interface isn’t perfect yet (the buttons should be bigger for easy TV viewing), but I think it’s pretty good for a first shot at this. The web server portion is based off of “Jürgen Schweizer’s Cocoa example code”:http://culturedcode.com/cocoa/.

“Check out this screencast”:http://www.riverfold.com/software/wiitransfer/screencasts/sharing.mov to see what most of it looks like. The first part shows the new Wii Transfer main window UI with a source list for switching features, and the second part shows what it looks like from the actual Wii. I just setup a tripod and filmed off the new HDTV with my digital camera.

I also started back on “real work”:http://www.vitalsource.com/ today. We have some neat stuff shipping later this month that I’ll be blogging about more once it’s ready to show. I knew I could easily get lost in inconsequential stuff on the Tuesday after a long break, so I spent a bit of time yesterday reviewing to-do lists and getting my head on straight. Got some real coding and design done today, so no complaints there either.

All in all, 2007 is starting off great. (Except that I still seem to be sick, but I’m going to try to ignore that for a bit longer.)

Mediocrity is the new application platform

Today marks the 4-year anniversary of this weblog. What better way to celebrate than with a discussion of web applications.

Willie Abrams said in a recent Campfire chat: “Web applications automatically have sync.” He hits on the fundamental principle of web applications popularity, and of course that has always been true. But the difference now is that some web apps are actually fast and usable too. (Gasp!)

The rise of rich web applications that seamlessly mix Flash or Ajax while still staying true to the roots of web architecture (REST design, open standards) has upset the traditional desktop market. I first wrote about this in “To-do lists and embracing the network”, which was in a sense a subtle wake-up call to Mac developers: adapt to the always-on internet or any college drop-out with a shared server will obsolete your app after a few late nights of Rails hacking.

But it frustrates me to see such praise given to web applications that, were they traditional, native apps, they’d be laughed away to obscurity or ignored. Ajax is a huge advancement, but that doesn’t mean that every application works well for the web. I’m sure Google engineers spent an incredible amount of work on Google Pages, but compare it to Apple’s iWeb and it becomes obvious how weak web application interfaces still are.

Luckily some people are working through the really tough problems. Ray Ozzie’s Live Clipboard may be the start of a whole new shift in web app functionality, allowing data to move between web sites and even out of the browser. But true drag-and-drop of structured data between a native app and a web site is still a long way off.

Let’s make some lists, starting with the good.

  • Good web applications are data-driven, multiuser, and use URLs everywhere.
  • There is some key component that is about the browsing experience. That might be sifting through large amounts of data, viewing old logs, finding people.
  • The kind of data requires an adaptable user interface, not something with a strict set of traditional widgets. HTML is perfect for this.

On the other side are web applications that might be built by a team of smart people and with a great technology backend, but the application concepts are confused. They don’t know if they belong in a web browser or on the desktop.

  • Mediocre web applications think that a single web browser window is an entire windowing system with movable child windows.
  • No features that actually have anything to do with the web. The result is that it adds no value to the web as a whole.
  • Trying to replace the whole Microsoft Office suite.

Something else is changing in the HTML/CSS/JavaScript platform. In 2004, Joel Spolsky wrote about how instead of picking Mac, Windows, or Linux APIs, developers are building for the web platform and can deploy to any user’s desktop. Cutting-edge web applications push that claim to its breaking point, as differences between Safari, Mozilla, and Internet Explorer often cause headaches for developers. It’s no surprise when Microsoft’s set of Office Live applications require Internet Explorer, but it is note-worthy when Google’s chat interface does not work in Safari. There is now a whole set of web applications that require the latest version of Mozilla and won’t work in anything less.

Five years ago we accepted that web applications were going to be useful but ultimately unfulfilling, joyless experiences. Now most web apps have risen from bad to simply mediocre. The truly great ones have a foundation and design that would still be unrivaled in a desktop app. These amazing apps are not content to reimplement an old application as a web app just to allow use from any machine, but they take it to the next step: rethink the problem, stay agile, and redesign so that it’s not just web-based, but it’s actually better.