Surprise! Four Links hits on Tuesday this week. Come and get them.
1. New Media Artworks: Prequels to Everyday Life
In a story related to Paul's piece last week, Golan Levin writes:
some of today’s most commonplace and widely-appreciated technologies were initially conceived and prototyped, years ago, by new-media artists.
Comparison of Aspen Movie Map (1978-1980) and Google Street View (2007).
Image arranged by Golan Levin
2. Lessons from a failed meeting with a Social Media Guru
Matt Daniels chronicles how not to pitch a client your expertise.
3. Making Money with Flash Games
Lost Garden has an extensive article about revenue streams for independent game publishers. Even if you're not into selling Flash games, there are some good thoughts to consider.
Ads are a good secondary source of revenue, but surely there are richer sources …? There is an obvious one, used for decades by all other game industries...why not ask the players for money?
4. The New Yorker Critiques the Kindle
Those used to reading blogs don't often see design criticism of this magnitude: Nicholson Baker of the New Yorker has 6,300 words on the Amazon Kindle.
I forced myself to read the book on the Kindle 2. It was like going from a Mini Cooper to a white 1982 Impala with blown shocks. But never mind: at that point, I was locked into the plot and it didn’t matter. Poof, the Kindle disappeared, just as Jeff Bezos had promised it would.
Art, Business, Clients, Criticism, Flash, Four Design Links, Golan Levin, Kindle, Social Media, The New Yorker, Video Games|
It's one thing to make sure that your personal or client website validates, but ensuring that your blog does requires a lifestyle change. Herein, DLB addresses three unexpected, day-to-day blog validation errors.
One particular point of pride for us here at DLB is the fact that we post on BlogLESS six days a week, and we simultaneously manage to keep it valid.
For the most part, once you've mentally committed to valid HTML, this kind of feat rarely causes a problem. However, for a very brief moment this fine Wednesday, I thought I'd share with you three fairly non-intuitive things that we've run into that caused us validation errors, and what you can do to prevent them.
It's not just Vimeo: All embedded videos can be made valid using the Flash Satay technique. Here, we look at some code from YouTube.
About a month ago, I wrote a post for BlogLESS about how to display video content from Vimeo with Valid XHTML using Drew McLellan's Flash Satay technique.
Recently, it occurred to me to make this explicit: You can do the exact same thing with videos from YouTube! So, in the interest of continued blog validation, let's take another look at what makes an embedded video invalid, and how to avoid it. We'll start with the generics, and then move on to the slightly more finicky YouTube requirements.
Apparently, the SiFR technique has some competition: Facelift Image Replacement. And from the features they're advertising, it looks like SiFR might be in trouble.
I haven't had much time to play with it, but I have to say that at first blush, FaceLift Image Replacement looks pretty impressive as an heir to Scalable Inman Flash Replacement (SiFR).
I've used SiFR on a couple of sites before, and while it can create a vast improvement in the visual appeal of a site, it can be a rather painstaking task to get everything perfect.
For those not in the know, both SiFR and FLIR (Facelift Image Replacement) are scripts designed to replace vanilla HTML and CSS elements with representations of text (Flash movies and images respectively) on a web page.
FLIR seems to address a significant number of these problems.
The validation enthusiast can't seem to get a break in today's fast-talkin', rich media world.
Last week, I posted a video hosted on the video-sharing site Vimeo, only to be met with irritating XHTML validation errors.
The W3C XHTML Validator FAQ suggested I try Drew McLellan's famous Flash Satay method, but I just plain don't have the patience to wrap every embedded video on this blog in another Flash movie, and besides IE7 fixed the problem that motivated the Satay technique in the first place.
On top of all that, this particular error was incredibly easy to fix. (Which does make you wonder why Vimeo didn't just fix in the first place!)