Software Development from Ryan

Often I’m presented with a new web application that has a fantastic new interface and I just don’t get it. For example, here’s the interface for chime.tv:

This is an neat application built on you tube that has a joost like feel. I can understand that this looks cool but there’s always been a usability issue that I could never pinpoint with flash interfaces like this. If you look at the YouTube interface now you may find it more inviting and familiar:

Flash use in this case is minimized to the media player. The rest of the interface is HTML based. The blue links are familiar along with the rectangular vertical scrolling layout. This is how I use my browser, clicking links and scrolling. I even have a wheel on my mouse for it.

Let’s look at another example thats not as obvious: comparing Yahoo maps which uses a Flash interface to Google maps which uses a HTML interface. Here’s Yahoo:

Here’s Google:

I would say that at face value Yahoo looks better (even though Yahoo is showing me Buffalo instead of Toronto!). But with Google’s those little blue links can do wonders. I know exactly what the interface is implying by presenting those links. If I click them they will take me somewhere. The list on the left in the Yahoo interface is also clickable but it is less predictable what will happen.

I’ve struggled with this type of uncertainty about Flash interfaces for a long time. No matter how good they look they just don’t feel right. I wrote an instant messenger app several years ago initially with a skinned interface. It looked pretty cool but I eventually reverted back to a standard interface with controls provided by the operating system. Recently I’ve given this some thought and have come to a conclusion. Constructed interfaces are better for usability that drawn interfaces, (no matter how good your graphic designer is).

Whats the difference? A drawn interface is one that is created in a program like Flash. Flash is a really great app but I believe it is better for animations and multimedia than application interfaces. Basically, with drawn interfaces you need to draw your controls. A constructed interface is one where you use preexisting controls to build your interface.

Yes, the preexisting controls can get boring but its something you have to live with. We need standards like this so that we don’t have to think about performing simple tasks.

There’s also the argument that with drawn interfaces or skins you can replicate any operating system control. This essentially is true but nearly impossible to pull off properly without an enormous amount of work. Take for example the Google Maps and Yahoo Maps example. Yahoo comes pretty close to making controls that resemble operating system controls. They take an operating system agnostic approach where there controls are a compromise between operating systems. Take a look at the scrollbar for example. It looks similar to a Mac scrollback but its slightly different. The scroll arrows are at the top and bottom like on Windows. Another thing to note is the text is all anti aliased. This looks find when you’re on an OS/browser that automatically does this. But if you’re on IE6 the having anti aliased links looks different. Different can be good sometimes but its bad when it causes the user to think for even a split second.

It will be interesting to see which direction this heads. I’m definitely on the constructed interface side of things using GWT which uses the native browser controls. Rich client applications are making it big in the browser and there is a lot of new technology coming out that aims to tackle this including Silverlight, JavaFX, and AIR. It’s good to know that the iphone is on the constructed side, and Apple knows usability right?

Originally they had a touch of Ajax with their “digg” button where a click would submit your digg asynchronously to their server and update the digg count without a page refresh. This feature had been around for a long time and proved to be elegant and easily usable. Of course the lack of a page refresh also saves quite a bit of server bandwidth, but this performance optimization was shadowed by the features usability. Now, Digg.com has just added a little bit more Ajax icing to their traditional web app cake.

Basically what they have done is replaced the threaded comments with comments that are dynamically loaded when the user expands the list. All of the technical details are discussed by the implementor Joe Stump:

Probably the coolest, technically speaking, portion of the new comments is the manner in which most of the page is created. No longer do we create static HTML in PHP and send you a huge HTML page. Instead we give you the basics and, via AJAX/JSON, we make requests to the API and dynamically create the DOM using the FlyDOM jQuery plugin. The FlyDOM JSON templates are a stroke of genius if you’re looking at loading JSON dynamically into the DOM. The advantage of this is that initial page loads are much snappier and you can load the threads you wish to read on demand.

In simpler terms, Joe Ajaxified the comment system using the jQuery library. If you look past a lot of the technical coolness that Joe is talking about you’ll find that the greatest improvement here is performance based. Initial page loads are dramatically reduced by incrementally loading the page. If you look past any Ajax hype this performance improvement is half of the Ajax promise. The other half is usability. And although usability shined with the initial bit of Ajax on Digg.com’s digg button, digg members have declared this new comment system unusable.

In all fairness Digg.com is working actively on fixing the usability issues. It is clear however that usability in this instance came second, which is a mistake.

I work a lot with GWT building full Ajax applications. This is a bit different than Digg. In my case Ajax is the cake. The things that the GWT team does makes me happy. Seeing this Ajax issue at Digg reinforces that the GWT team is moving the project forward in the best direction. To understand this we can simply compare two quotes, one coming from JQuery and the other coming from GWT:

You start with 10 lines of jQuery that would have been 20 lines of tedious DOM JavaScript. By the time you are done it’s down to two or three lines and it couldn’t get any shorter unless it read your mind

Dave Methvin, JQuery front page

This sounds great to me. As a software developer I know the best code is no code. Or less is more. Digg.com made a good technical decision to use JQuery. But this is only half of the story and the half that developers usually tackle the best. Where is the other half?

We want great results, where “great” is defined by how much it benefits end users. Sometimes there are conflicts between what is easy for us developers and what benefits end users the most. When the two are in conflict, end user experience almost always wins.

GWT Team

I don’t think GWT would be the best solution for the Digg comment system since Digg just needed icing for their traditional web application. However, this is really the proper additude to have when developing applications that you want people to use.

Coincidently I’ve just finished writing a GWT example application that acts as an Ajax database administrator for a social news website like Digg.com. It’s a full Ajax application and the fifth example application in my book on GWT Applications. It illustrates how to dynamically load and save all data using JSON or XML on REST or Actions , or using GWT RPC…. basically a lot of server interaction techniques. Its tested on PHP scripts, Ruby on Rails, and a Java Servlet. Althought most of the technically interesting things are not visible, here is a somewhat underwelming screenshot of the applicaiton:

Adobe Apollo, now called AIR, (Adobe Integrated Runtime), the runtime environment that allows you to use existing web technology for apps on the desktop is an obvious next step from building desktop like Ajax applications that seem to be awkwardly confined to a browser window. The technology requires a runtime installation of approximately 10MB, similar to the need to install the Java or .NET runtime to run apps in these technologies. However, AIR stands apart by allowing you to develop your applications using web standard technologies. It also adds desktop application like features including storage on your hard drive.

Also providing storage is Google’s recently announced Gears browser plug providing SQL database like storage from web applications. Both Gears and AIR technologies are responding to a web user’s need for offline storage for their web applications. In favor of gears, the download size is under 10% of the download size for AIR. It appears to be a better solution if you only need to add offline storage to your web application.

On top of offline storage, some of the sample applications for AIR offer a mix of Flash vector based and DHTML user interfaces. Its good to see Adobe taking advantage of Flash, which Macromedia made the most successful browser plugin of all time. And it has had relatively no competition. Until now. It had its crown taken as the king for responsive web applications with the rise of Ajax. Flash is now primarily used for ads, music, video, and games. However, Ajax has not yet won in the category of web application interfaces. A big battle is going on between Google Maps, an Ajax map web app, and Yahoo! Maps, a flash based map web app, (I have to side with Ajax in this case. I still feel like I’m in an emulated environment when I use a flash interface. The buttons aren’t real. This is also one of the downfalls of older Java client apps).

Of course Microsoft sees this battle going on and wants a piece of the action. They have always had great development tools that have really pushed client application development on windows and are now trying to push web application development in the browser with its Silverlight plugin. Silverlight is a very interesting technology that supports a subset of the .NET framework. This means that it is like AIR providing better integration with OS features but differs by running in the browser. The download size is also a subset of the size of the .NET framework at approximately 10MB.

With Microsoft getting in on the action Sun is reminded of an old grudge. It is the company behind Java and once had a compelling browser plugin like Silverlight that provided richer desktop app like features inside the browser. Java applets still crop up from time to time but have nowhere near the usage that Flash has. Recently Sun announced JavaFX as a lightweight framework to build rich applications that seems to be a response to Microsoft’s Silverlight.

As a developer of client side web applications this can be very confusing. Do you write an Ajax application with web technologies like JavaScript and leverage Gears for offline storage, or use ActionScript to build an app based on Flash, or use .NET languages for Silverlight, or Java for JavaFX. Thankfully Adobe AIR has decided to leverage existing web technologies. This is one reason the web has become a better application platform for many apps than the desktop. However, Silverlight and JavaFX use non web standard technology because Java and .NET are better for building and maintaining larger and more complex applications which web standard technologies were not built to handle.

This brings us to where GWT fits in. It uses Java to allow developers to build larger applications and compiles the code down to web standards. It can’t be used to build the multimedia applications that Flash is known for, and Silverlight and AIR are aiming for, but it is the most compelling solution for building Ajax applications.
From a corporate perspective, It’s refreshing to see these large companies providing innovation on the web. It is important for them to have a decent amount of web technology real estate. And with many multi million dollar acquisitions of Web companies this web technology competition fits the place of the Netscape/IE competition in a modern day dot com bubble.

Links:

• Adobe AIR
• Google Gears
• Microsoft Silverlight
• JavaFX
• Google Web Toolkit

I started working on this game back in October 2006 initially stemming from a chat with Jay Bibby from Jay Is Games, who earlier posted a favorable review of Gpokr. The chat was about how we both loved Taro Ito’s Dicewars, which Jay had also reviewed, and thought it would be great as a multiplayer game.

Most of the development was finished by the end of November so I opened it up for testing to Gpokr players who were waiting for the December competition to start. Word traveled fast and Jay showed up on the tables within the first few hours and several hours later had the first review of Kdice up on his site.

It turns out Jay and I were not the only ones who wanted multiplayer Dicewars. Over the past few months over 30,000 players have signed up to help me test and tweak things here and there. At this point things are fairly stable. Making the game multiplayer has added a great politcal aspect on top of Dicewars’ mix of luck and strategy. There is also rating system based on ELO and different tables for players with higher ratings.

Introducing the Multiplayer Strategy Game Kdice

The GWT team always seemed open to the idea of making their Ajax toolkit open source. In fact it sounded like that was an eventuality with the only reason for not doing it initially being that they wanted things fairly solid first. Well, they’ve finally done it.

This is good news for GWT developers. While Greg Wilkins and I were working on getting Jetty Continuations working with GWT ,changes had to be made to GWT code We were somewhat concerned about this since we weren’t certain how receptive the GWT team would be to outside changes. Although I’m sure we could have worked with the GWT team to get things working there was no indication that they welcomed this sort of thing. Making the toolkit open source is a welcome mat for contributions like this.
Thanks GWT. Stay tuned for some info scaling GWT Ajax communications with Jetty Continuations.

Dietrich Kappe has a nice post on the Pathfinder Agile Ajax blog about Bruce Johnsons remarks on the complexity of building tools for dynamically typed languages.

I think its important to note that, along with the halting problem, the reason that dynamically typed languages like javascript don’t have great tools is because they started out as languages for small tasks. Their advantage is that they don’t need complex tools - maybe just a text editor. You can whip up a script, debug, and maintain it very fast.

In contrast, typed languages are designed from the start for large maintainable projects. The extra language features they have are there for more than the support of their tools. They support readability, organization, and compile time error checking.

In other words, why make a tool for a language that wasn’t designed for tools? Why use a scripting language for a large project? Also, why build applications on web technology designed for documents? I can actually answer that last quetion… but another day .

There was some talk about Dojo during the GWT podcast with Bruce Johnson, Robert Hanson, and myself comparing it to GWT to build Ajax applications. Dojo has been around longer and may be more mature, GWT leverages java’s development tools, etc.

GWT really excels over the development lifecycle but the one area that I thought it fell behind, and did not think it had much of a chance of catching up, is with the fast tweak/test cycle that fits scripting so well. With GWT you would refresh your browser to see your changes but since GWT compiles java to javascript this would be much slower.

A release candidate for GWT 1.2 was released yesterday with an speed improvment for refreshes during debugging. Bruce Johnson suggests the most efficient develop method with GWT 1.2 in this issue report:

Now caching between runs. Startup is 20-30% faster, and refreshes are much, much faster. Since refreshes are very fast now, the most efficient way to develop is to leave a hosted browser open, make source changes, then click “Refresh”.

I tested this with gpokr and found that startup was 25% faster and refresh was about twice as fast - still not as fast as a refresh of a fully compiled gpokr running in a browser which is a remarkable 1 second. Compare this to the 7 seconds it takes to load the Dojo sample mail application in firefox, (this app seems to have far less functionality than gpokr so it should be faster, this illustrates the advantage of compiling code to javascript eliminating the need for nice looking, readable, debugable javascript that is a tradeoff with speed).

Gpokr was running for about 3 months before I realized that IE’s 2 connection limit per hostname and a hanging HTTP connection is a risky situation.A hanging connection is when the Ajax application makes a request for data and the server waits with an open connection until data is avaialble. When data is available it is returned immediatly simulating an instant notification from the server.

This is why gpokr seems to always be moving. Cards are dealth, bets are placed, and chat happens seemingly instantly.

It seems like a hack but there are not many options to out there that give Ajax applications the ability to receive data asynchronously from the server. Yes asynchronous is part of the Ajax achronym but this is just asynchronously getting data from the server. For an event driven application like poker the client needs to get data only when it is available. Of course it could check the server every few seconds but this can be a massive overhead. A hanging connection lets the client idle until there is something to do.

The problem is that it takes up a connection. I’m ok with this on the server but the browser limits 2 connections per hostname. Thats one to hang for events, and another to send a chat message, but what if a picture needs to be downloaded at the same time. It needs to wait. Or, in the case with gpokr, what if one connection is hanging for events, the other is downloading a large image, and you only have three seconds left to make a call on pocket Aces or you’ll be folded by the server. The server folds you and you get very mad.

It doesn’t seem like this issue is talked about much within Ajax development circles. Although I ran into this article that measures the use of multiple hostnames to improve performance of a web page - essentially making more connections available to load the page in parallel.

Now, for gpokr, I use one hostname for hanging calls and another for HTTP objects so that the hanging call never slows down the sites action.

How long can you go without clicking on a website interface is the question asked by this user interface experiment posted today on Ajaxian. The website experiments with building a clickless interface and it pulls it off fairly well. It doesn’t take long to figure out how to navigate menus pages with only movements of your mouse. Thier idea comes from the fear of a mouse with ever an increasing number of buttons. They have clickless experiments and and games to show that mousless interfaces are functional and even suggest a humorous product that would help ween you away from clicking a mouse:

The site is fun although its less of an academic experiment and more of an art exibit trying to make a point. It looks like click statistics are measure possibly to come to some type of conclusion but the experiment is presented almost like a game: see how long you can go without clicking. Of course, when there is a button that your told not to push we tend to have an urge out of curiousity and defiance to push it to see what happens.

My mouse has four buttons and a scroll wheel that clicks like a button. I’ve actually have grown accustomed to using all of them but think that any more would be excessive.

Interfaces should always be simplified, but I doubt the definitive action of a click can be fully replaced by mouse movements. However, after playing with this site I can see how interfaces could be simplified by using less mouse clicking.

I had the opportunity to join in on a round table discussion podcast with Bruce Johnson, technical lead of the GWT project at Google, and Robert Hanson, keeper of the GWT widget library, hosted by Java Posse.

GWT Round Table