Shebanator

I have seen the Silverlight…

•16Apr07 • 6 Comments

So TechMeme is chock full of news about SilverLight, including the patented Microsoft astro-turf announcement technique, where all the Microsoft WPF/Expression employees post the same links to their blog without actually saying anything new and substantive. The best post is the real announcement from Tim Sneath. The other post worth reading is this one from Loke Uei where he has a handy comparison chart listing Silverlight vs. WPF vs. Flash/Flex. Too bad the column on the Flash/Flex stuff is almost completely incorrect. Every other post from Microsoft’s folks is pretty much worthless.

But what did they actually annnounce at NAB? A decent new name (by Microsoft standards it is excellent since it only has one compound word) and a really boring new logo. The runtime downloads have been renamed but the bits themselves are the same pre-alpha stuff from a couple of months ago. No news on actual Expression support for Silverlight either. Some teasing about the miniCLR “surprise feature”. Guess they want to save all the real news for MIX. All that’s left for NAB is hype, hype, hype. The wow is back!

Meanwhile Apple and Adobe actually had new never-before-seen products to talk about, not just new product names.

Posted in Uncategorized
Tags: Microsoft

Friction(less) Rails

•14Apr07 • Comments Off

I’ve been thinking quite a bit lately about solving problems at web scale, so I’ve been following the story of Twitter with quite a bit of interest. There was a bit of a flap recently when Josh Kenzer interviewed Twitter’s Alex Payne. Alex made some statements about the pain of doing very large scale scaling with Ruby on Rails that caused a bit of controversy:

Running on Rails has forced us to deal with scaling issues – issues that any growing site eventually contends with – far sooner than I think we would on another framework.

and:

None of these scaling approaches are as fun and easy as developing for Rails. All the convenience methods and syntactical sugar that makes Rails such a pleasure for coders ends up being absolutely punishing, performance-wise. Once you hit a certain threshold of traffic, either you need to strip out all the costly neat stuff that Rails does for you (RJS, ActiveRecord, ActiveSupport, etc.) or move the slow parts of your application out of Rails, or both.

and:

If you’re looking to deploy a big web application and you’re language-agnostic, realize that the same operation in Ruby will take less time in Python. All of us working on Twitter are big Ruby fans, but I think it’s worth being frank that this isn’t one of those relativistic language issues. Ruby is slow.

That is what I’d call “tough love”. Ruby on Rails fans may not want to hear about these things, but that doesn’t mean they aren’t real problems when you try to scale at a massive level like Twitter is doing.

Unfortunately but not too surprisedly, the initial reaction to these statements was pretty defensive. Since then, though, there has been a lot of good discussion of what it means to scale in Rails. The best discussion, though, has been from Ryan Tomayko, who says:

I picked up a word from Joe a few years back and find myself using it a lot: “friction.” When referring to framework and tooling, “friction” is a (subjective) measure of how much the tooling gets in your way when trying to solve a specific-case problem. I’ve come to evaluate frameworks based on two rough metrics: how far the framework goes in solving the general case problem out of the box and how little friction the framework creates when you have to solve the specific-case problem yourself. When a framework finds a balance between these two areas, we call it “well designed.”

Measured along these lines, there are portions of Rails that have a less than perfect balance but I don’t think multi-database connectivity is one of them. It seems to me that moving too far in one direction on this would cause lots of friction for moving in other directions. There just doesn’t seem like there’s a lot of general case to solve here when you dig into the details.

I love that quote on friction: it really captures the thing I like best about Rails. His entire article is well worth a read, both for the insights into good framework design and for the specific extensions he and his cohorts made to Rails to make it work for what they were doing. Great stuff and I hope the public conversation continues like this.

Posted in Dynamic Languages
Tags: Scalability

The Death of UI Consistency

•12Apr07 • 18 Comments

Yesterday, John Gruber posted a gripe about the new CS3 panels and palettes and how horrible it is that Adobe put the close box on the right side. To John, this seemed horribly un-Mac-like, and in trademark style he concludes his gripe with an elitist and unsubstantiated slap at Windows users (but hey, at least it was funny):

Ends up the title bar controls for palette windows in CS3 are on the right side, Windows-style. “X” for close, “_” for collapse. God, that just looks so wrong – how did this ever get approved? If Adobe really wanted to put these controls in the same location on both platforms, why not do it the Mac way? If Windows users cared about consistency, they wouldn’t be using Windows.

I wrote him an email where I explained what I thought the actual motivation for the close box on the right decision was: the desire to save vertical space by putting the close box to the right of the palette tab panel interface.

But thinking about it some more, I realized that this answer didn’t really satisfy me. First of all, even though putting the close box on the right does make sense from an overall design point of view, the fact remains that the close box doesn’t look like a Mac-style close box when you run CS3 on a Mac. It doesn’t really look like a Windows close box, either. Instead, it looks like an “Adobe close box”, just as the palettes themselves don’t really look like those of other, non-Adobe applications. But then I had to think about it some more, because despite this realization I still am not bothered by the problem whatsoever when I actually use CS3, and I like to think I have a pretty well tuned design aesthetic (for an engineer).

The reason, I think, is that the goal of a single, consistent platform look and feel, as espoused by John in the quote above, is dead. Long gone. Apple never really achieved this even in the good old days (remember HyperCard? FileMaker?). And looking at Apple’s own applications that ship with a new Mac shows that things have only gotten worse. Its always been a case of “do as I say, not as I do”, and never more so than today.

But I don’t blame Apple or Adobe for the death of the goal. What really killed that goal once and for all was the web. Where once there were only a few popular Mac applications that broke with convention, on the web look and feel consistency isn’t even on the list of things to worry about. YouTube and flickr look and work completely differently. Users today have been trained to expect a different set of UI conventions from every web application they use, and they aren’t complaining about it.

The trend towards Rich Internet Applications using Apollo and its ilk will further cement this trend, as web applications come down to the desktop with their web UI conventions intact. To me, this is a good thing.

[Update 10:36AM] Wow, this is getting a lot of traffic and a lot of comments, especially for something I wrote at 4am when I couldn’t sleep. I want to make a few things clear to people about my intent.

The real thrust of my article isn’t as a defense of putting the close box on the right vs. the left, or about what the ‘x’ looks like. I personally don’t think that discussion is all that important, although there are clearly a number of commenters who disagree.

What I’m really talking about here is how the goal of complete UI consistency is a quest for the grail, a quest for a goal that can never be reached. The fact that you call it a holy grail may make the quest seem more noble, but it doesn’t make the grail any more achievable.

At the end of the article, I talked about how RIAs bringing web conventions to the desktop was a good thing, but I didn’t explain why (I blame lack of sleep). The reason I think this is that it lets us move the conversation away from the discussion of conformance with a mythical ideal and towards a discussion of what a usable UI should be. I really appreciate the comments from folks pointing out places where Adobe’s UI isn’t as usable as it could and should be – they’re the folks who really understand what I’m trying to talk about here.

Finally, I want to point out for those who may have missed it that this is my personal blog and that these are my personal opinions. I am an engineer, not a PR mouthpiece or an evangelist (at least not professionally). Furthermore, I don’t work on CS3, so my opinion shouldn’t be taken as that of the CS3 team or of Adobe as a whole. I never cease to be amazed at how many people seem to confuse this issue.

Posted in Rich Internet Applications
Tags: Apple, Microsoft

Volkswagens and Porsches

•04Apr07 • 1 Comment

Ray Ozzie has done an interview with the always excellent Knowledge@Wharton folks, and its a great read. Its nice that Ozzie is coming out of hiding a bit. In the article, he talks quite a bit about Adobe. Not surprisingly, Dan Farber and Ryan Stewart are talking about it.

I think Dan pullled the most interesting quote out of the article, though he didn’t include the whole thing. Here it is:

Well let me just start by saying that, in my view, we only have one shared future as a software industry. And that is centrally deployed code that has a different lifetime associated with it on the device it’s deployed to.

So, what is HTML or DHTML? Most web pages have JavaScript in them. That’s code that is delivered to the client and it has the lifetime of the browser instance you’re using. Flash — what is that? Well, it involves enhancing the browser runtime by downloading code. But it tethers those enhancements to the service and the lifetime of those things is still within the browser. With Apollo, maybe you can make the lifetime that of the user on that device. They have increased the lifetime from the browser instance to the PC.

All apps — whether Win32 code, Flash code, managed WPF [Windows Presentation Foundation] code — are going to have those lifetime choices and will all be centrally deployed, whether that central deployment is from an enterprise or from a service provider on the web. The concept of CD-based installs, floppy-based installs or USB stick installs are artifacts of a time when we were not fully connected.

I don’t see radical differences in the approaches that Adobe might be taking, that we’re taking, or that the web industry in general is taking. The languages and run-times may be different. And we come at it from a history of the desktop coming up to the web. They are coming from a history of being on the web and going down to the desktop, but the endpoint is the same.

Cool. Ray Ozzie gets the key benefit of Apollo – bringing the web down to the desktop. His key message here is that bits is bits, and that it doesn’t really matter whether its .NET code or Flash or HTML/Javascript that gets deployed on the web – they all end up just being code that runs on the local machine. There is truth to that, but I think he is either being a bit disingenuous or missing the larger point – it isn’t just about the bits, its also about the APIs and tools used to create those bits. Does Ozzie really believe these things are irrelevant? I doubt it.

I’ve written about how I see our vision differing from Microsoft’s in this key area previously, but instead of repeating myself, I’ll instead point to the work of Peter Fisk. He is working on an amazing project to create a complete Smalltalk environment from the ground up, built on a lisp base. Now this is a pretty ambitious project, you have to admit. He started off using .NET and WPF, back in July 2006. After making steady progress for six months, he heard about Flex 2.0 at the end of January 2007. Two days later he had posted his first proof-of-concept tests of lisp implemented in Flex. Within a month, he had significant functionality in place. A month later, he had animation working in Smalltalk. He’s made incredible progress in the last two months, way more than he did in six months with WPF, and I’ve had a blast watching his progress. Now he has had a chance to reflect on the two worlds, and I love what he has to say. Here it is in its entirety:

I have been coding almost exclusively in ActionScript for the past two months, and I am beginning to like it.

The entire Adobe way of doing things is a lot simpler than Microsoft and it seems to produce results that are just as good. So far, I haven’t found anything that I could do in C#/.Net that I can’t do in ActionScript/Flash – in fact, I am finding some capabilities in Flash that aren’t available in .Net.

Here is a car analogy:

Microsoft has built a sports car and Adobe has built a Volkswagen (a real Volkswagen, not the new imitation ones).

So while Microsoft is preparing their latest rocket-powered turbocharger which will be available “real soon now”, you can actually build and deploy stuff in Flash.

A Volkswagen on the road goes a lot faster than a sports car in the repair shop.

Now, a lesser man could take that analogy and run it into a telephone pole, but I won’t go there. 🙂

Posted in Rich Internet Applications
Tags: Microsoft