For years the NFL.com site has been using RealMedia for their video streaming. They finally updated their site and are now using Flash video. Go Team!!!

Beyond that they have greatly increased the amount of video they are delivering. Each game will have video highlights and they have lots of interviews and analysis delivered with Flash video. Their video player has maximum dimensions of 640 x 360 and has a full screen mode in IE but not Firefox.

I checked the source code of the homepage and they are also using the SWFobject to embed the HTML code dynamically to get around the Internet Explorer’s Eolas/ActiveX activation crud.

Preseason practice

On the downside I had lots of problems browsing to some of the videos and getting them to play correctly on a Win XP machine with IE7 and Firefox 2.0. Of course the commercials play just fine but the content often fails to queue up.

The video content navigation is handled in HTML so the problem is likely the Javascript communication between the HTML container page and the Actionscript. It’s amazing how often that gets messed up but as everyone knows Javascript can be more than a little finicky. Hopefully they’ll get that sussed out before the regular season is underway.

Close, but not perfect

They could have used video.Maru for their video player but it doesn’t look like they did. Oh well, I can dream. :-)

Fantastic

As a fan I couldn’t be happier. I’ll be on the NFL.com site on a daily basis during the football season. I don’t have cable TV because there isn’t much to watch besides football and the History/Discovery channel. The way things are going it won’t be much longer before I’ll be able to watch anything I want via the Internet.

Addendum: one day later

I’m working with one of the dev’s at NFL.com to help trouble-shoot the problems I mentioned above. Here on my system at home everything works flawlessly. At my friend’s house on the same setup I had all sorts of problems. Don’t you just hate it when that happens?

Suppose someone created a web based calculator. All it does is the basics of add, subtract, multiply and divide. Would you call that a Rich Internet Application (RIA)? Probably not.

Now suppose someone created a web based calculator that let you graph equations. Would that be an RIA? More likely.

Suppose someone built a web based calculator that kept a history of your calculations and you could interact with them via a mouse by dragging them around on a canvas where they would automatically update their results based on location. As a for instance suppose I have a column of numbers all added together on my canvas. I then drag the result of another calculation over into that column and it automatically copies itself into the column and updates the sum.

Would you call that an RIA? Very likely.

That example could be built with a handful of different frameworks. So RIA has nothing to do with the fact that you may have used Ruby, Ajax, Flash, Flex, etc.

What made that last example an RIA is the User eXperience (UX).

Now lets go back to the original example of a simple calculator. This one works by the user clicking on the canvas and then typing in an equation, sum of numbers for instance. There is no support for dragging results around or anything like that. You just have the ability to basically create a napkin with a few tabulations on it.

That’s nothing special and probably wouldn’t qualify as an RIA for most people. But lets add one more feature. I can give this napkin a name and invite others to view it. Even update it or add comments at the bottom. Now is it an RIA? Very likely.

Even though there is no cool interface there is the social aspect of being able to share data and comment on it.

So there are at least two paths to building a Rich Internet Application. By making a dynamic interface that gives the user the ability to create results that would not be possible in the physical world. Or, to create a rather mundane application that can be shared with a larger group in a way that would be prohibitive in the physical world.

Note: nothing of actual use follows. Just a few thoughts about the plugin formerly known as WTF/e. (What The Frak/everywhere)

The first thing I thought of when I saw that Microsoft had renamed WPF/e was, “Amazing, they picked one of the few English words that have no rhyme.” Not that it matters but I know how anal those marketing folks can be about naming things. They’ll probably call a staff meeting to discuss the global socio-economic ramifications for using non rhyming words in a product name and how that will impact product penetration along the Asian rim.

The name that they ended up with - no, I’m not going to use it - just slides off the memory cells somehow. Kieth Peters noticed the same thing.

On a less technical note, I gotta say, I HATE the name. I can’t ever get it right. I’m stumbling over Sparklelight, Sprinklelight, Silverfish, etc. before I spit it out. John Grden suggested “Steely Dan”, but we won’t go there…

Then I did a search for Silverfish + ‘the other name’ and found that a few others are having just as much trouble remembering the name as myself. And I swear as the god Apollo my witness that I independently used the name Silverfish in some comment on someone’s blog in the past few days.

Without having any experience developing with Silverfish I’ll wager that no one can create a custom video interface with it as fast as I can with Flash/video.Maru. (Shameless plug but hey, it’s my fraking blog.)

I don’t have anything to add when it comes to actually testing Silverfish’s capabilities or development environment because I don’t plan on installing the player much less developing for it. I’m backed up with Flash jobs as it is and I don’t think anyone’s going to pay me my freelance rate to learn Silverfish for them.

If you, dear reader, happen to be a Microsofty and want to accuse me of being an Adobe fan-boy who doesn’t know half of what I think I do then let me save you the trouble. You’re right. Point made. Now move along.

Ryan helps clear the confusion surrounding the various RIA technologies. (But Ryan, why wasn’t Flex at the TOP of the list?)

After seeing a story about Flex on Digg, I decided to do a round up of the newer Rich Internet Application technologies including how you build with them, what they’re best suited for and where to find more information about them

read more | digg story

I read a lot of technology news and blog sites. Most of these sites have comments enabled for users to chime in with their own observations and opinions. If you’ve read many of these comment threads then I’m sure you’ve noticed a great deal of vituperative statements regarding the merits of one technology or another. It’s amazing the ire that Flash and Flex draw from the Ajax crowd but it goes both ways. I have politely dissed Ajax a few times myself.

A few days ago I was reading a post at The Universal Desktop by Ryan Stewart where some of the comments were borderline rabid. I don’t get much of that sort of commentation here on polyGeek.com because it’s pretty much a Flash only site. But Ryan writes on a broader range for a popular site - ZDnet .com - so he gets readers from the full spectrum of developers.

So why is it that, for instance, many Ajax developers will comment disparagingly about Flash when clearly they don’t know much about it besides that it’s used for web page adds. (I still have to grit my teeth every time I read that because most web adds are GIFs with annoying Javascript plopping them all over the page.) I’ve also seen .Net developers dump on Java developers, Apple zombies insulting PC abusers, iPod vs Zune, the list goes on and on and the insults go both ways. And of course the most obnoxious offenders of all are the Linux OpenSource preachers and the Web standards/accessibility evangelists. It doesn’t matter what tune you play, you just can’t please anyone in those two groups.

This got me to thinking, “Do other professions have the same sort of bickering that we do? Take music for instance, which is something I don’t know much about, but I just don’t see a bunch of violinists going to clarinet blogs and writing things like, “Clarinets are so music 1.0. I can’t believe they still teach people to play those outdated, unusable instruments…” Really, I’m sure this doesn’t happen. I’m sure that musicians are just as competitive as any other group. But I think music has been around long enough to mature to the point that musicians realize that a symphony requires an orchestra. And what’s important is how good they are at what they do. Not how another instrument works to play the same tune with a different sound.

The analogy between music and web programming is apt in another way. I doubt if many developers or designers think of it this way but code and pixels are a form of expression just as music is. I personally love Flash because as an instrument it has the functionality to allow me to express myself. Sure, there are things it won’t do. But a violin doesn’t sound like a drum either.

There are a lot of projects to do out there on the web - and soon the desktop. But there aren’t enough Flash developers in the world to keep up with the demand. Nor are there enough Ajax, WPF/E, PHP or anything else developers. My advise is to drop the my toy is better than your toy attitude and get busy pushing the envelope in whatever framework you choose.

We all have a lot of work to do and money to make. How does that sound?

Ted Patrick, the Flex evangelist, put together a great summery of the top ten myths about Flex. It’s his job to get the word out about Flex and I think he’s doing a great job.

I had the question posed to me:

First and foremost the user should have a good experience. If you always make your decisions based on that then you’ll get it right most of the time. Another thing to keep in mind, and this applies to any user input, only ask what you need to know. If there is something that you want to know but is not essential to the task then don’t ask.

For instance, if you’re working on a site for an online grocery store then resist asking for things like the users favorite vacation destination just so you can target ads to them. I know, I know, you would never do such a thing but believe me, someone in marketing will ask for something equally inappropriate. I find it useful to carry rubber bands with me to meetings like this so that I can shoot people for asking for things like that. :-)

With that said here are a few suggestions:

If the site is all HTML then stick with HTML forms. Conversely, if your site is all Flash then do the forms in Flash.

Go with what you know. If you’re comfortable with one or the other then go with that. You’re more likely to create something that the user likes if you like what you are using to create with. Basically, if you can’t stand working in HTML then by all means, don’t use HTML to create your forms. You’ll be more likely to cut corners just to get it done.

Flash is obviously more expressive that HTML. If you want to create something that goes beyond the typical experience that people have with HTML forms then there’s your answer: Flash.

Advantages to Flash forms:

• You can control the font.
• Both Javascript and Actionscript are equally adept at client side validation. However, in the Flash environment you have more options for providing feedback to the user.
• I would give Flash a slight nod when it comes to maintaining state with the use of Local Objects.

The only intrinsic argument I can think of against Flash forms is the old, “What if they don’t have the Flash player?” cliche. We’ll when you’re doing something that is leveraging the browser DOM heavily your more likely to find people who have browsers that aren’t up to snuff but do have the Flash player.

I think that if you say to yourself, “I want to create the perfect user experience for using my forms.” then you’ll want to go with Flash because of all it offers. But believe me, the Flash part will be easy. The UX (User eXperience) work will be the most time consuming part.

If you do go with Flash then keep in mind what version of the player you are publishing for. If you’re not using anything that requires the latest player then don’t publish for it. Go as low as you can. For a project like this that will likely be version 6 or 7, depending on the code.

Last thoughts, just about anything you can do with Flash forms you can do with HTML/Javascript. However, if you’re really going over the top and manipulating the interface as the user progresses through the forms then the HTML approach is going to become more and more problematic.

With HTML you’re going to have to test in multiple environments. My biggest concern would be how my perfect forms are going to work on browsers in 2-3 years down the road that aren’t even out yet. I’d be in a “Here’s Johnny” mood if I had a bunch of HTML/Javascript that IE7 just took a crap on. With Flash, you’re just about guarantied that what works now will work later.

(first published as a comment at Anne 2.0: Towards Hybrid Ajax/Flash/Java Browser Apps)

When people talk about the future success of Ajax and Flash they take it from the developer’s POV and ask questions like: is it open source, need a plugin, etc. Those questions will have very little to do with the success of either platform. It’s always about the bottom line and that’s cost of development and support.

If the ACME company wants a RMA then they probably don’t know the difference between a socket and a vector shape. They take their idea to a few different design/development firms and say, “how much and when?”

I don’t do Ajax development so I can’t say how long it might take to develop in that environment but I find it hard to imagine that it’s going to be faster than developing with Flex/Flash (Flesh). And even if they can both be developed in the same time for the same cost then there is still the question of support. From an Ajax standpoint there is always the consideration that code will have to be tweaked when new browsers are released. That won’t happen with Flesh.

So I can’t see many design houses that are married to the Flesh approach deciding to add Ajax to their skill set but I can see the Ajax crew developing some Flesh skills. It will start with video and then spill over more and more into just developing as much as possible in Flesh.

JD over at Adobe gives a beatdown/retort to some Ajax evagalist.

Adobe/Flash has bent over backwards to accommodate the Ajax crowd. Flash has a robust interface for communicating back and forth with JavaScript. The success of Ajax does little to hold Flash back and might even help promote it in the long run. However, the opposite is not true.

If someone really wants to settle this, or at least put a big nail in this argument, they should hold a contest. Set up the backend server with the database and all and then give a team of experts in Ajax and another team of Flex/Flash experts a deadline to complete the client side interface. Then let users vote on which one they like the best.

I think it’s important to have an accurate estimation of the time involved in the work because that’s needed to get an idea of what the cost of development might be. You would also want a number of teams for each project and additionally a number of projects to give an accurate baseline on what each environment is capable of.

Of course one of the projects would have to be video/audio based. I want to see how an Ajax team might pull that off without using Flash. :-)

If someone really wants to do this I’m sure there’s a way of setting up this contest so that it’s fair and accurate. Go Flash!!! :-)

Nice interview with Kevin Cheng, Senior Interaction Designer at Yahoo! Maps and Local, on why they chose the Flash platform over Ajax.