Ajax and Smart Clients

We’ll soon be having an interesting conflict between the recent Ajax hype on one hand, and the trend of "smart clients", which includes "offline capability" in its tenets, on the other hand. I found myself complaining today about the otherwise nice task list application "Remember the Milk", which is Ajax based, and thus available online only. Well, I was on the train, and the GPRS connectivity was very bad. And I wanted to administrate my tasks. Well, luckily, I’ve got OneNote as a spare. But after this experience, I’ll be looking for a task list application which is usable offline as well. I’ll let you know what I find (I hope it won’t be Outlook…). Ajax clients are definitely not smart, and it’s hard to see what we could do, architecturally, to make them smarter.


Video Calling, and Festoon Review

I just had the reason to try video telephony (and application sharing) over the web, for a remote training session. Never done that before! First of all, I have to say that it was a pretty absurd experience. Both sides have a web camera on top of their monitors, so if you want to look at the other person, you won’t be looking at him from his point of view. And vice versa. So, either you look into the camera, and you don’t see the other person, or you look at the picture of the other person (who’s probably not looking into the camera, either), and appear not to be looking at the other person. But you get used to it. It’s confusing at first, but then, you just have to decide where you want to look, and why. Probably it’s best to look into the camera when you’re talking, and not at the picture of the other person. Because then the other person will probably be looking at your picture. And will appear to you as not watching you. But that’s OK, since you’re looking into the camera, and not at the picture, anyway! Perfectly consistent, when you get it.

So, enough psychology.

The other day, I found a free Skype plugin, called Festoon (previously vSkype), which provides video telephony, and application sharing, too, as a bonus. It’s sponsored by commercials, but these are mainly about online poker, and since I’m not interested in that, I’m OK with those. 🙂

Festoon is in beta version, but it works very well. The video quality is very good even over a pretty slow connection, and since it uses Skype for the sound, the sound quality is very good, too. The synch between audio and video isn’t perfect, however. You can invite any number of participants in a call (I’ve only tried two), and I guess you’ll see them all side by side, then. You don’t have to mess with opening ports in your firewall, like for example when you’re using MS NetMeeting or MS Messenger, and that’s perfect. Easy to use. However, it’s not yet completely integrated into Skype. That’ll come, I guess.

And the "application sharing" feature is much better implemented than in MS NetMeeting or MS Office LiveMeeting. In both of these, you can’t share the window of an application if it’s covered by some other window, for example, if you want to check your mail while the other persons are trying to understand your incomprehensible PowerPoint slide, they can’t see your slide any more. But this works in Festoon! It must be looking at the in-memory bitmap of the windows when it shares the application.

A drawback with the application sharing implementation is that you can only share one application at a time. I guess sharing more applications will be implemented in a non-free version. And you can’t let the other side control your application, either. But this is sufficient for many purposes.

My guess is that video telephony won’t be very popular until there’s a way of solving the problem with the camera position. Perhaps we could have two cameras, and let some imaging software interpolate a picture of you that looks as if you’re looking into the camera, when you’re actually looking at the picture of the other person? I have no idea if that’s possible.

Architecture Astronauts and Web 2.0

Joel Spolsky is so very annoyed by the Web 2.0 term:

The term Web 2.0 particularly bugs me. It’s not a real concept. It has
no meaning. It’s a big, vague, nebulous cloud of pure architectural

I wonder if the problem comes when we attribute something "architectural" to it. I don’t think it is. As some kind of "visionary fluffy concept", it can certainly have some meaning. I have no problem with that, such concepts can be OK for what they are. But the architecture astronauts will most certainly use it for their purposes; I guess that’s when we’ll all be annoyed.

Developer and Vendor Oriented Languages

DevHawk (Harry Pierson) has written an interesting post about "vendor oriented" versus "developer oriented" languages. I agree with his remark that

Projects don’t fail because developers can’t change the language’s concept of
inheritance. They fail because the gap between the abstractions provided by the
language and the abstractions needed by the solution are enormous. Modern
software development is like building skyscrapers with Lego blocks.

Certainly, in order to build the abstractions to bridge that abstraction gap, all the proper lower level building blocks and abstractions need to be in place (that’s an argument for adding "int?" to C#, for example). But those lower level building blocks do not need to be modifiable! Changing the concept of inheritance, huh? Sure, that could be nice at a research institution, but not in industrial software.

RSS for Subscribing to Anything

Nick Bradbury writes about "reading list subscriptions", basically subscribing to OPML files. A great idea. But why stop there? Couldn’t we just subscribe to anything on a standardized XML format, by inserting into an RSS feed items conforming to a specific XML schema? I’m most certainly overlooking some technical complications here, in particular, that we would stop keeping things simple. But anyway, by inserting more and more stuff into RSS feeds (we’d like to subscribe to anything, wouldn’t we?) we will finally reach a point where such a generalization is inevitable, I believe.

AJAX and GUI Responsiveness

I’ve always been thinking that web GUI applications are terribly stone-ageish, compared to their rich-client counterparts. But with the advent of AJAX and Web 2.0, we’ve actually gotten something that’s better than what we get in traditional GUIs: GUI responsiveness. In order to make an ordinary GUI responsive, we have to let user actions spawn actions in separate threads, which cannot directly update the GUI, since typically, GUI APIs don’t allow updates performed in anything but the main thread. So, lazy programmers always skip making some of those operations asynchronous, and the GUI won’t be very responsive as a result.
But web GUIs always respond to clicks (well, as far as the browser GUI is responsive; that’s not always the case, just watch Internet Explorer), so the web application GUI itself will be responsive whether the developer of it wants or not. So the developers are forced to address this, on the server. But no longer does the problem of updating the GUI in a single thread exist, since the browser and server are separated over the network.
It is possible to build response rich-client GUIs, but too few people are actually doing it.

Update (same day): The responsiveness has always been there in web applications, of course, regardless of whether AJAX has been used or not, but not until now, web GUIs have reached a standard where they can favourably be compared to traditional desktop GUIs.