Star Wars

Adobe and Ruby Welcome to Web2.0 — it's just like web 1.0. Only this time, it's personal.

Ruby on Rails is really a lot like PHP. It provides a nice framework around which you can wrap style requirements. It provides in-line substitution, the same as PHP. This lets you write snippets of HTML, and design general layout CSS, and piece it together in a nice way, even though the content itself is dynamic. That means you can still maintain a style contract, even though you have no idea what you are displaying. It makes web design very hip, very modern ... modern like 1999.

But Ruby on Rails goes further, selecting patterns to base the divide-and-conquer approach. The main pattern (Model Controller View) goes further than formalizing dynamic content style contracts, it makes the backend development easier. (Now, with Rails 1.2, it goes further, and apparently supports fully RESTful V-to-C-to-V communications - if I understand that correctly.)

All-in-all, this just makes Ruby up-to-date with modern approaches to web design. Approaches that must cater to small development groups, and full-out companies like Google. But, adhering to DRY principles and Ruby-elegance, it does it beautfully. And it lets you make that happen fast. If you need some convincing -- like, how fast -- check out their 15-minute video.

That's not to say that you couldn't do this in 15 minutes with your choice of framework in JAVA. It's just to say that, if you like Ruby, you can do it in Ruby. That's actually a great selling point though: Ruby is a beautiful language. The short answer is just that: Why Ruby on Rails? Because it's a beautiful language. It's not because you can do anything unique. It's because you can do it in style. And that's fun.

The long answer is pretty much the same. But it qualifies fun a bit. Fun is addictive. Fun is popular. Popular is where the people are. And people is where the innovation is. So Why Ruby on Rails? Because you like innovation. Again it isn't that you couldn't do it in another language. There will be real strides and cross-pollination going on between Java and Rails. Java will probably prototype a lot of where Rails will go. And it isn't like PHP doesn't already have the allure of a huge user base. But that's now. Rails is where the people will be.

If that sounds like a really steep hill to climb, a lot of promise and no practicality: you're at least half right. But think about it this way: everything important now, from AMFPHP to style contracts, from design patterns to useful shortcuts: it already exists. People just need to reapply those things in Rails, and it will happen. There's some great statistics that show just how heavily entrenched web design is in PHP. But just compare the new projects to the far less new code in Rails, and you might reconsider.

Okay, but what does Adobe have to do with it?

If this topic addresses you, you're probably not coming at web design from the design side of things. Adobe already has everything to do with web design. Dreamweaver has become something of an archaic tool, but only because everyone had to compete with it because it had become the de-facto standard. It has colored everything from BBedit to even TextMate (which really has nothing to do with CSS, but anyway). Then there's Photoshop, and to a lesser extent Illustrator. These two tools process huge amounts of images, mostly because they are the right tools for the job -- and are equally standard (actually, far more superiorly).

To see illustrator (at least illustrator-like) design in web images, check out Qunu, or to see what you can really do with it if the web isn't your output restrictions, check out Amateur Illustrator. I provide no sample of photoshop: A sample of photoshop seems almost a moot point.

Then there's Flash. Everyone loves a good Flash site (and hates a bad one): it's eyecandy. Let's get serious about eyecandy, though. Eyecandy is not a 3 minute intro screen covering a pure CSS site (though, yes, it can be.) Eyecandy is not 50 Flash objects to load on each GET/POST (though rarely, that works too). This is eyecandy. (Please do notice the page source as you browse these.) Imagination Cubed is eye candy. And Script.aculo.us is too (check out their wiki too). Maybe this is too.

Of the three, I have to say, the iPhone is the mostest. But that page on Apple isn't quite there, is it? I mean it's great, just like Dave's link at the end. But there isn't enough complexity to get you. At least if you're like me -- you want gloss like iPhone but complexity like ... well, you want gloss wrapped around standard GUI bits. You want to make your web page function like a piece of business logic, but feel more like Star Wars (navigate to the demo reel).

And that is what Adobe has to do with Web 2.0. With Adobe Flex, you get the gloss of Flash Animation, with the cut-and-paste user interface of, well, pretty much your desktop. And best of all, they really did it right. All the modular thinking and programming work can be done by the programmers, all the tweening and animation can be done by the deisngers (using Flash, which fits in nicely with Flex, sine it's almost the same technology). So with those kind of tools, can you make the user interface you've always wanted? Well, no, you can't. First, you have to see how to fit it all together, you have to do all that work, too.

Next Up - At the foothills of two Mountains: RESTful Rails and Flex

Direction

Like any idiot, I'm going to just post a stream-of-consciousness until enough gets out here that it starts to take shape. What better way to start a blog?

It must have been back in 2000, that I first discovered Ruby. It was billed as this beautiful, SmallTalk-like language with Perlish sensibilities. Being a web programmer at the time, that looked alluring. So I downloaded the rpm, and played with it. My first code was probably something like:

class World
  def initialize
    @@identity = "World"
  end
  def identify
    return @@identity
  end
end
class Communicator
  def introduce_to ( introduction = nil, to_object = nil )
    addressee = (to_object == nil)? "nobody!" : to_object.identify
    puts introduction || "Hello, " + addressee
  end
end

w = World.new
me = Communicator.new
me.introduce_to( nil, w )
=> "Hello, World"
me.introduce_to ()
=> "Hello, nobody!"

Which is really quite charming, and thrifty. But then, I went back to my perl code to do any real work. That's because (I was a scripter and) perl has this wonderful thing called CPAN, and in it, you can find a library to almost anything. Perl was never a pretty language, it was just pretty at how easy it made doing real things. Ruby might support things like somestring.gsub!(/swapme/) { |x| "you're swapped" }, but it didn't support things like outputting to an HTTP client.

Enter Ruby on Rails. (And, lots more, it's six years later now.) That wild and crazy community, they built up Ruby to the point that it can handle web programming! Where were you guys six years ago?! I've gone and left development, and started doing design! Sure, I leverage my development skills, I'm kinda doing both things at once, but mainly now I'm a designer. Now Ruby has a way to handle all things POST and GET, when I'm worrying over CSS, and sRGB! Sigh.

Well, maybe I still have an in. I am, for all intents and purposes, the webmaster for our site. That is the seed of an idea that has led me here.

It turns out, not only am I rusty on web development, but Rails, and more importantly Adobe, are turning it inside out. There's a little bubble of newness in web development that means, if you weren't riding it, you've got a lot to learn. And no, browsers still don't support PUT and DELETE. That's why Adobe is in the picture. Rails, all-the-while, is trying to fill the vacuum that PHP, SOA Java, and Perl CGI are (possibly) going to leave behind — yeah, even Java. They are going WebDAV/SOAP because they want the same paradigms on all ends of development.

(My stance on this is not, BTW, that SOA is inferior to REST; broken REST through web standards or otherwise. It is that technology follows its users, and the hundreds of people cranking out tens of applications that tie into 30 year old databases aren't going to count as a majority when compared to the thousands of small-team shops and tens-of-thousands of really small team shops.)

Next topic — how do Adobe and Ruby on Rails address web development. And why should a designer care?