Software Development from Ryan

What a wonderful thing to hear from a company I have a tremendous amount of respect for. KDice Trainer is featured this week on the App Store and shown as the #2 icon on the front page. It started with an email from Apple the other day:

“We love the game, KDice Trainer. Can you send us the artwork for it - according to the specs below by Friday morning?”

Of course I rushed to get this to them ASAP knowing that communication from Apple of this sort meant some type of promotion and App Store promotion typically gives an app a large boost in exposure. The artwork was sent, now the app is featured, and I see some sales coming in.

So I’d like to give a big welcome to all the new KDice players out there! Practice up. I’m getting the multiplayer code ready for you.

KDice Trainer for iPhone is now on the App Store! I worked on making a fast single player version of KDice that captures all of the elements that make kdice.com popular. You play against up to 6 out of 99 bots and work your way from 100th place up to 1st if you’re lucky.

The interface is clean and clear and allows you to configure the type of game (2-7 players, map size, difficult) without a configuration screen. Configuration screens are confusing and often make things more complex than required. In this app there is no configuration screen but instead these configuration options are built into the leaderboard where you select who you want to play.

The leaderboard has 99 bots named after some of the top KDice players. The AI is fairly complex giving each bot unique decision making combinations. As you work your way up the leaderboard the bots get smarter and harder to beat.

The touch screen on iPhones is a natural fit for selecting areas to attack. You simply slide your finger from the territory you’re attacking from to the territory you want to attack. Even with a full map attacking is easy and accurate.

The landing page:
http://iphone.kdice.com

On the App Store:
http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewSoftware?id=310652813&mt=8

Do you want a free copy?. I’ll be giving away 10 (9 left) free copies to people who can promote KDice Trainer for iPhone most effectively (blog post, tweet, digg, etc). Simply email me what you’ve done and I’ll send a free copy to the top 10.

I just ported chapter 10 from my GWT book to the Java App Engine. I’m very impressed with Google’s release today. I had to:

• upgrade Eclipse to use the new Google Eclipse Plugin and create a new Web Application Project
• change the code to use JDO instead of Hibernate since this is what App Engine uses
• click the “Deploy App Engine Project” button in Eclipse

and it was up: http://gwtapps10.appspot.com

I really value GWT for the way it solves the software engineering issues with Ajax and thick web clients. I always discourage selecting technologies based on how quick it takes you to get a app compiled and running from scratch but damn, this is by far the quickest way to deploy a full stack web application using the absolute best possible technologies available (google’s scalable infrastruture, async http, image bundling, monolithic javascript compilation, easy RPC)
Thanks Google!

I’ve attached the source code if you’re interested. Send me your thoughts and updates!
GWTApps-DatabaseEditor-AppEngine.zip

(I’ve removed the jars from the zip because they were too big (war/WEB-INF/lib). You should copy the required libs back to this directory. Use the Google plugin to generate a new App Engine web app and copy the jars from its lib directory.)

Although Kongregate won, KDice was nominated for the Best Time Sink category at The Crunchies. TechCrunch, a very big blog reporting on technology start up news, put on the event in a style similar to award shows you’d see on TV. Award winners included Digg, Facebook, and Tesla Motors - pretty amazing companies. Here’s a screenshot from the Time Sink category which KDice was nomiated in:

Google Web Toolkit Applications has been out for around for one month and a couple reviews have come in.  Joseph Ottinger from The Server Side says in his review:

Google Web Toolkit Applications is an excellent book, well worth the list price of $49.99 (USD) if you’re doing any serious GWT development. It’s well written, very much in depth, and shows application patterns that will be very useful for anyone using GWT, in many cases showing concepts that are very difficult to find elsewhere.

The second review is by Chris from GWT Site:

Google Web Toolkit Applications is an excellent book. It is easy to read and does a really good job covering all the major GWT topics and more. The applications demonstrate software development best practices and cover a variety of interesting techniques.

The conference was amazing. The only negative point, and this is the most tiny negative relative to everything else, would be that there was a bit of a pro Java slant at times which alienated developers using many other technologies. I guess its a sure fire way to get a positive response from a largely Java based audience. This however, was not something that any speaker from the GWT team did making a point to convey Java as a pragmatic, rather than religious, choice.

On the largely positive side of things, some of the most interesting people I’ve ever talked to were there. Bruce Johnson is an extremely practical no-compromise web purist and his dedication to GWT makes me feel lazy and Joel Webber’s depth of thought about the most specific details was wonderful. The rest of the GWT team were just as incredible. They all evoked a great amount of trust in the development of the toolkit. Their priorities are for the users of web apps and nothing else, not even Google itself - except in the sense that what’s good for the web is good for Google (of course helping the developer helps the user in many cases). The people attending the conference weren’t slouches either. Some of the brightest and most progressive developers were there. I found myself enthusiastically listening day in and out.

Adding to my positive experience was seeing my GWT book in print for the first time, watching it sell out by the second day and climb to #5 on Safari’s top books. Woo hoo!

Ajax is a bit of a browser hack.  Isn’t it one of these Web 2.0 trends that are going to eventually fade away into obscurity?  You would think it would be gone by now in the same way we’ve found better solutions for things like frame sets and animated gifs. But it’s not. People have embraced websites that use Ajax.  It’s not that they’re simply attracted to the latest technology.  Most people don’t know that browsers aren’t meant to do these Ajaxy things. For that matter do most people even know what Ajax is? Mostly no.

As software developers our intuition tells us to build something that does the same thing with different technology, something more elegant. But the reality is people love the internet and their web browser. There’s a sense of safety (browsing compared to installing software), and infinite content. It seems that we need to suck it up and see what we can do with this Ajax thing.

Progress has been made over the last couple years to deal with this software development problem starting with quality frameworks started to popup like Prototype, Ext, and Dojo. Then we started to see better tools. The tool I’ve been most impressed with for Ajax software development is the Google Web Toolkit (GWT) since it lets you leverage software engineering tools from Java.  At this point I think we have this Ajax thing handled pretty well. Frameworks have abstracted the limitations of the browser allowing us to focus on writing application code with a solid foundation. Software engineering tools now provide us with the proper environment to scale our development process and application complexity.

So what’s next? Let’s nail performance…

Google’s open social has a web page now and it looks like a fairly straightforward technology to use. I’ll definitely play around with it a little bit. Unfortunately it’s not quite ready with the social networks. Only a few of the networks listed support it today including Orkut, Plaxo, and Ning. It sounds like Facebook may even support it even though Google left them in the dark.

This is a pretty big API announcement for Google. Probably the biggest over the past year or so. It supports standard web technology, which means you can build sophisticated apps using GWT too. It’s a very good move by Google and helps with their image of being open and not evil (although supporting MySpace and not talking with Facebook looks pretty bad). They even held an little event called Campfire to announce the API. Campfire is Google’s attempt at a Barcamp/FooCamp/DemoCamp style unconference, but unfortunately it had that fake corporate video/infomercial feel instead.

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: