Le Maitre d'Something

Flash Gets Searched

2008-07-22T09:24:00.000-07:00

I'm obviously a few weeks late on this one, but I've been on vacation. (A computer-free, cell-phone-free vacation, I might add. Try it sometime - it's pretty incredible.)

Anyway, Flash is searchable, or at least Google has an algorithm for it. Adobe says in this article:

"Google has already begun to roll out Adobe Flash Player technology incorporated into its search engine."

This page outlines some details from Google's end. At the moment, they're only indexing text within a SWF file - not images or video. But the implications are huge.

I've acknowledged that the most reasonable criticism of Flash is the inability to search the content within it. That's been a huge limitation, and anyone that's trying to build a highly searchable site has avoided Flash for that reason alone. We'll have to see how valuable the search results are that are generated from Google's new algorithm, but that limitation is becoming irrelevant.

What's really huge about this is that the FlashPlayer "plug-in" has made another giant step toward transparency. This is (in part) Google and Yahoo admitting that Flash is a core means of transmitting information over the internet. If GooHoo is expecting to find Flash content, they're expecting end users to have it installed. It's a transparent medium - everyone expects that Flash content is viewable. When it's not, something is wrong. With the typical plug-in, the expectation is the opposite (that it's not installed), and that's even what you plan on.

Maybe you're more skeptical, and you think that this is just Adobe swooping in at the right moment, leveraging the GooHoo/Microsoft conflict to give FlashPlayer a (HUGE) leg up on Silverlight. Maybe Google and Yahoo aren't admitting anything about Flash as a core means of transmitting information. Guess what: it doesn't matter. Motives aside, FlashPlayer gains some huge ground not just as a plug-in, but as a platform.

Interdisciplinary Tensions

2008-06-10T16:19:00.000-07:00

During the 5 or so years I spent working at Mattel, I was in a sort of odd place between the creative and programming departments. I was hired into the interactive group - a predominantly creative one - because of some odd circumstances, but most of my work was technical. So I spent a fair amount of time with (and sometimes between) designers and programmers. Both sides thought I was one of them, so I would hear gripes on both sides. Don't get me wrong, Mattel was a great place, and our teams worked together phenomenally. But there's always potential for gripes between the two, and sometimes that potential is realized.

At the end of the day, I'm a programmer. But working between groups makes you realize the very real dependencies. At Mattel we were making games, so it was really emphasized. Programmers usually make ugly games without some serious creative help. Without the programmers, designers have some nice looking screen shots. Both are equally worthless.

The dependencies don't feel as real when you get into application development. There are some really great tools that will allow a programmer to create a working piece of software, but without a good user interface designer (or a programmer that's into both disciplines), you still usually end up with something that feels like a traditional Microsoft app (i.e., not great).

The UI is what makes you look good. A killer app with a bad UI is like driving a Lotus covered in Bondo. It's impressive under the hood apparently, but I've never seen it. And that's the point.

So if you're a programmer, and you haven't bothered, dig into some design theory. It's actually quite interesting, and much less about emotion than what your stereotypes will let you believe. Some good starting points:

A two-part series by Mauro Marinilli on UI Theory: Part 1 | Part 2
A classic article on Fitts' Law from Bruce Tognazzini's site

Marinilli's first article has a slew of resources at the end as well. If you know of some great ones, please share!

My point is this: I've had a lot of opportunities open up to me because managers or clients have viewed me as "having design ability." I don't consider myself a particularly good designer. But just having some basic awareness, and being able to integrate it in some basic way, works wonders. People become impressed, and sometimes that even gets reflected in your paycheck.

Game Code vs. App Code

2008-06-03T11:46:00.000-07:00

Jeff Fulton has written a great article about optimized game code, including some pretty thorough performance tests. He also gives some great historical information about OOP trends in Flash gaming based on his personal experience programming games.

What makes Jeff's article rare is that you don't see a lot of game developers seriously considering and integrating OOP practices. There are performance hits associated with some OOP structures (getter/setters versus public variables, etc.) that turn a lot of game developers off. Someone that's just doing games doesn't always take (or think they have) the time to learn good system architecture.

Application programmers have no excuse. If you're building apps, you aren't concerned about performance hits that will drop your application from 90 to 60 frames per second. You could probably run your app at 30 fps and be just fine.

Applications also have potential for a more elaborate system architecture and an increased likelihood of revisions or updates by other team members. Good OOP code is crucial for those things. The only detraction to strict OOP practices in Flash is performance related and frame rate specific - and apps rarely come close to pushing those limits.

Before I get flamed by game developers, let me qualify that by saying that a good portion of any game should actually be considered application development. Typically a game is actually an application that houses a game engine. (Jeff essentially comes to the same conclusion.)

So really, nobody has an excuse. Game and app devs alike need to know good OOP practices. Gamers just have better excuses (in certain circumstances) for breaking the rules.

Little Bits of Finesse

2008-06-02T10:09:00.000-07:00

Sometimes it's the subtle elements that can really make your work stand out. But those finesse elements are often the 2% of a project that require 50% of your time. It seems counter-intuitive (especially when a deadline is looming), but it's those scenarios where you're often best rewarded for putting a little extra into making reusable code. You invest a little up front for long term payoffs.

For example, plenty of games have a scoreboard. It's relatively easy to just populate a text field with the user's score, but if you spend a little extra time to make a more elegant, reusable solution, your game will feel just a bit richer. People that play it may not necessarily notice that your game has a "special" scoreboard. But they'll know something's just better about your game. And if you've encapsulated the functionality well, you may not need to build another scoreboard for a long time.

Here's an example. This isn't all that complex, and the effect is relatively subtle, but it's a bit more interesting than simple text field updates. I also built it for flexibility. A fast-moving game may have a lower tween duration and higher blur distance. A slow-moving game would have just the opposite. Need a 10-digit score? No problem. And altering the font is as simple as changing a library symbol.

My recommendation, if you haven't already: start developing your own class library, and keep it as a formal repository of all the bits and pieces you use all the time. If you find yourself creating something for the bazillionth time, give yourself some extra time to create a solid implementation of that piece. Don't build everything into it, just the essentials. That will give you a core version, a starting place for future implementations. You'll save yourself a ton of time and, if you go a little out of your way, you'll easily add a bit of finesse to future projects.

Pattern Extremists

2008-05-29T15:33:00.000-07:00

It drives me a little crazy when people (including myself) become emotionally charged during an argument. It always dilutes the argument or kills credibility - or both.

Programmers have plenty of emotionally charged debates, and while design patterns is probably not at the top of the list of polarizing issues, it's one of them. Some programmers really work themselves up into a childish frenzy, and it sounds like it's the folks on the other end of the spectrum that they're ranting about.

These rants really aren't about the patterns, or the idea of patterns, but the people using the patterns. If people are cutting+pasting from the GoF book, that's really not an issue with the pattern concept. "But patterns encourage that behavior," says the pattern-hater. I'd say that laziness, lack of education, or a need to feign proficiency might encourage that behavior. If design patterns didn't exist, those people would be copy+pasting from other sources that would likely be less well thought out.

The other rant usually revolves around patterns promoting obscure terminology. I agree, but only a little. Throwing around pattern names to non-programmers communicates nothing. But if I'm reading a bit of technical documentation that identifies a class as a Singleton, that saves paragraphs of reading. (And if I don't know what a Singleton is, I've got a great learning opportunity on my hands.)

It's another tool vs. user argument. The tool is great when used effectively, and horribly destructive in the wrong hands. Don't blame the tool for the error.

Flash: Disambiguation

2008-05-27T22:59:00.000-07:00

After almost 10 years of working with Flash, I sometimes make the mistake of assuming that everyone knows what Flash is. Most people can't succinctly define it - they have their perceptions, but it's vague. Maybe you're someone that can define it. Kudos to you, but ask your spouse, friends, or family. They may even know you as someone that "does Flash stuff." But ask them what Flash is and you get partial answers at best. In a lot of minds (don't underestimate how many) "Flash" is an ambiguous term. Sometimes that ambiguity turns into hostility, especially among developers that turn their noses up at Flash "faux-developers."

I'm no "Flash Evangelist" - if you want to use religious terminology,"Flash Apologist" is more appropriate. There are great apps out there built with other great tools and technologies. But Flash doesn't always get a fair shake.

What Flash Is

The reason for some of the ambiguity is that when people talk about "Flash," they're usually talking about one of three things:

Flash the Authoring Tool - the software we use for making...
Flash content - the files that load into...
FlashPlayer - the browser plugin that lets people view Flash content.

So, you get ambiguous questions like, "Do you have Flash?" Unless that question is coming from another developer, the person is probably really asking, "Do you have FlashPlayer?" It's not an easily answered question like, "Do you have Firefox?"

Another classically ambiguous question: "is that a Flash site?" Here "Flash" really refers to the type of content being served up.

Throw in Flex and the terminology gets more confusing. Flex is a just different way to author Flash content (which still plays in FlashPlayer). If you're a Flex developer, a question like, "are you a Flash developer?" isn't an easy yes or no question. You still make Flash content, and it's still delivered via FlashPlayer, but you may not work with Flash the Authoring Tool. So you're answer is, "well yes, but..."

I think some of this is why Adobe started referring to the "Flash Platform," but that's just another ambiguous term. It's only relevant to those within the Flash/Flex development community.

I don't know how to demystify the terminology. Within the Flash community, it's not a problem. But for everyone else, the terms create ambiguity that drives perceptions...more on that later.

What Flash Does (and Doesn't)

A whole lot of people hate Flash and Flex, and with good reason - they've been heavily misused. Any good tool in the wrong hands makes a mess. Any honest Flash developer has to admit that they've used Flash more than once when they really didn't need to. But used well it's amazing.

The common exceptions:

"Flash is bad for search engines."
Yep, it is. There are good ways to compensate for some issues (and have been for some time - neither of those ideas are all that new). But for many people - not just developers, but project leads and management types - SEO is the thing you do later, so it never happens.

This is probably Flash's biggest constraint. That's not a reason to throw it out - constraints are good. The way around it? Don't use Flash to display big blocks of text. Obviously that doesn't cover every scenario (shopping carts come to mind...), but there's usually no need to show pages and pages of text via FlashPlayer.

The other big exception is for people developing SaaS products. If you've created a Flex app, for example, you probably don't need the actual app to be spiderable. Maybe the app generates content that you'd like to make searchable - but that's outside the scope of the actual application. What does Google need to know about the internal workings of a Flex application that it can't find out from plain text on your product website? If you're not going to explicitly plan for SEO in your Flash website, leave text out of Flash. That solves about 95% of this gripe.

"Flash is bad UI."
Actually, no. This is the equivalent of saying "hammers smash thumbs." It depends on the proficiency of the guy holding the tool.

Some people still really enjoy citing this classic as authoritative. Yes, people abused the tool. But in 2000 we were also still writing ActionScript using dropdown menus, and you could make $60k right out of high school working for a dotcom. People learn, and things change.

One point that Flash-haters often overlook at this point in the debate is that HTML is equally capable of creating some hideous UI. Give a bad designer any tool, and it's going to be garbage.

"Flash takes a long time to load."
Assuming that "Flash" here means "Flash content," the answer is also no, it doesn't. There's nothing inherently heavy about Flash. Ask anyone that's ever had to meet the bandwidth requirements for creating ad banners - you can cram a LOT into 30k.

The bloat comes in when a designer/developer disregards file size. You have to optimize any media, and the complexity of optimization grows with the capabilities of the media. Optimizing a static image is quick. Audio takes a little more attention. Video even more. Flash the most. So do you throw out the power tool because of the risk of injury? Sometimes, maybe. Other times you just work with care.

"You have to install a plugin."
Yes, but you probably already have it installed. You have to be pretty aggressive to avoid Flash anymore. In fact, you probably have to install a plugin to keep the evil Flash content away. Adobe has done an amazing job of making Flash updates almost seamless, hence the ridiculously high adoption rates. (Good luck, Silverlight.)

Perhaps I've overlooked something, but Flash is the most ubiquitous plugin in the world. More web users have FlashPlayer9 than have any one browser. More web users have FlashPlayer 9 than have Windows, even. It's arguably the most consistent way to deliver web content at all.

There are plenty of other gripes, but I'll have to hit those some other time. The bottom line: Flash does rich media. Applications, video and audio, games - even banners and animations - are Flash's niche. Yes, other things can do this stuff too, and if you like those, great. Remember, I'm not trying to make converts. But don't go on a rant about how much you hate Flash or Flex without giving it a fair shake. Remember that like any tool, there's a learning curve, so don't gripe if you make novice mistakes and something doesn't work.

Perceptions

If you're a Flash developer, this is all extremely important because perceptions drive what people think you do. I write code all day, but a lot of people (that know me well) think I'm an animator or designer of some sort. That's inconsequential maybe, but what if a project manager has some misconceptions? And what if that PM works for a potential client/employer? You could be talking about SaaS development with Flex, and they may blow you off because "Flash is for making games." Or worse, they may listen to your whole pitch and bring you on board to create banner ads. Blech.