Archives

I guess its my turn to spin out historical analogies. Does anyone remember GEOS? That’s right, a GUI OS for the Commodore 64. In those early days, everyone rolled their own GUI  (character mode windowing…yum). Some were good, some were bad, some were downright ugly. GEOS was an attempt to bring the unifying influence of an OS that provided the basics of a GUI to the C64, something that Windows brought to the PC and the Mac OS brought from the beginning to the Macintosh. GEOS and the C64 faded away, but the days of the custom crafted GUI were numbered. All that stuff is and should be baked into the OS.

We’re in a very similar situation when it comes to the browser and Ajax/Widget libraries and frameworks. Everyone is rolling their own widgets, developing their own DOM and Ajax utility libraries and frameworks. I think the next step should be obvious. Bake an Ajax library into the browser. Can you imagine having Ext already present and available in your JavaScript runtime? Imagine the boon this would be to standardization, code reuse, etc.?

On Monday, Richard F. Cecil of UX Matters published an interesting piece titled Documenting the Design of Rich Internet Applications: A Visual Language for State. In it, he discusses the challenges facing information architects in the Ajax era. Full of practical, how-to advice for IAs and developers, it’s already prompted some interesting comments. I’d recommend it to anyone interested in the process of developing RIA specs.

A few months back, some former colleagues of mine – both of them top-notch IAs – approached me about putting together a panel discussion about just this topic. The panel never happened, but our initial discussions got me thinking about the role of IA in RIAs. As web-based user interfaces grow more complex and modular, many of the traditional approaches to IA fall by the wayside. Steve Hansen, a commentator on Cecil’s piece, nails the problem:

As someone who designs and builds complex RIAs, with complex non-linear work flows, I have been struggling to find the ideal modeling vocabulary. Things get even more interesting when you have complex server back-end functions. I currently use a hodge podge (technical term) of wireframes, UML activity, sequence, and communication diagrams and whatever else seems to fit the bill. This is surely an area ripe for discussion and exploration.

It’s clear to anyone who’s ever worked on even a moderately complex Ajax application that screen-based specs don’t cut it. Unless documentation breaks things down into individual components, controls and user actions, it will fail to capture all of the possible conditions. Even a component as commonplace as an image carousel or a rich-text editor includes more discrete points of user interaction than an entire webapp did five years ago. Throw in something like keyboard commands – a topic Cecil’s piece doesn’t broach – and the complexity multiplies. And let’s not even talk about the need to document accessibility modes.

I’d be interested to hear from people with more of a desktop software background – the same folks who are flocking to GWT – about their approach. I don’t know much about IA in the desktop world, but I imagine that webapp IAs will be looking there for inspiration. Desktop GUI frameworks don’t offer the free-for-all that HTML, CSS and JavaScript do. There’s less freedom, but there’s less of a burden to reinvent the world over and over.

That’s why the GWT or Ext model offers productivity gains not just for developers, but also for IAs and designers. If your interface is built out of standardized widgets rather than build-your-own components, much of the documentation can live at the widget level. Application IA then benefits from a shared vocabulary in which common interactions have already been described and it’s only corner cases and the interplay between components that need individual documentation. Users win, too, because they don’t have to figure out how, for example, your date-picker works; it’s just an instance of the same date-picker widget they’ve used in other applications on the same platform.

As Ajax UI toolkits mature, it will be interesting to see how their authors balance the desire for completely customizable interface components with the productivity and usability gains of componentization. At what point do bells and whistles cost more in complexity than they deliver in novelty?

Technorati Tags

• information architecture
• usability
• JavaScript
• Ajax

Speaking of GroovyTestCase, I experimented a bit with using both it and JMockit as an alternative to GWTTestCase.  This may sound strange at first– after all, the point of GWTTestCase is to exercise your code in the way it will eventually execute as JS at runtime.  What I’ve effectively done is to run my tests from within Groovy against GWT classes compiled-as-Java.  First I will go through an example of what I’m talking about, then I will summarize some of the thoughts I had as a result of going through this exercise.

Below I have an implementation of KeyboardListener which modifies the contents of a TextArea based on keypress.  I want to test the behavior of this listener.  Here’s what I did:

1) Write a test.  I did this using Groovy, but you could just as easily write it in Java using JUnitTestCase if you prefer.  This particular test verifies that my listener will append an equal amount of whitespace to the next line when the <enter> key is pressed, and position the cursor at the end of that new line.  Very simple stuff, but worth testing even outside of GWTTestCase.  I find that the Groovy style keeps this test case a lot shorter than it would otherwise be in Java.

class SampleTest extends GroovyTestCase {
    private static final char KEY_ENTER = (char) KeyboardListener.KEY_ENTER
    private static final int NO_MODIFIERS = 0;

    protected void setUp() throws Exception {
        Mockit.redefineMethods(GWT, MockGWT)
    }

    public void testEnterKey() {
        def keyListener = new MyKeyListener()
        def textArea = new TextAreaFixture(text: "    abcd", cursorPos: 8 )

        keyListener.onKeyPress(textArea, KEY_ENTER, NO_MODIFIERS)

        assertEquals "Content is incorrect", "    abcd\r    ", textArea.text
        assertEquals "Cursor position is incorrect", 13, textArea.cursorPos
    }
}

class TextAreaFixture extends TextArea {
    String text;
    int cursorPos;
}

2) Mock out com.google.gwt.core.client.GWT.  This ultimately comes down to mocking out the ‘create’ method.  Notice below that we make a special case for ‘DOMImpl.class’.  The reason for this is that the actual DOMImpl is decided at runtime.  It is also referenced in the constructors of the widget we are testing (i.e. ‘TextArea()’).  Note that this class needs to be a Java class (i.e. non-Groovy) due to the way in which JMockit redefines methods on existing Java classes.  As for why I return ‘null’ for everything else, I do this to fail fast in any cases I’m not testing.  As it turns out, this is all I need for the testcase above.

public class MockGWT {
    public static Object create(Class classLiteral) {
        try {
            if (classLiteral.equals(DOMImpl.class)) {
                return new MockDOMImpl();
            }
            return null;
        } catch (Exception e) {
            throw new RuntimeException(e);
        }
    }
}

3) Subclass com.google.gwt.user.client.impl.DOMImpl.  Ah-hah!  Here’s the catch… This step provides us just enough code to satisfy construction of our Widgets.  For my purposes, I let my IDE generate this subclass for me, and stuck with the default implementations it generated.  I return an instance of it above.

public class MockDOMImpl extends DOMImpl {
    public Element createElement(String tag) {
        return null;
    }
    [...]
}

The approach to this style of testing intercepts any calls on the Widgets themselves before anything is allowed to hit the underlying DOM implementation.  What I provide above is just an example of how this could be done, specifically when testing behavior of custom classes that happen to inherit or reference GWT classes.  Testing things like layout or UI concerns is another matter, but one which I would not consider ‘interesting’ enough for unit testing, since most of the behavior on the UI can be easily inspected by viewing Widgets as simple beans.

So why would you want to attempt this anyway?  First, I happen to like working in Groovy, so I crave more reasons to do exactly that.  Second (and more pertinent), much of behavior I find interesting in GWT apps revolves around simple message passing.  I trust GWT enough to do its job once I leave the Java space.  Beyond this are some philosophical differences I have with GWTTestCase, particularly since GWTTestCase makes it hard to maintain a larger body of unit tests, requires additional configuration in your module file (or as I’ve done before, constructed a different “test-only” module file that inherited from two module files), did not let me set up tests the way I would like to, etc.  I could go on.  When unit testing, very little of the logic I write is made less interesting or less relevant outside of a JS runtime environment, so where possible I would like to gain some benefits from treating everything as Java.

There are other benefits.  There’s the noticeable speedup in execution time when running entirely within the JVM.  There’s also less restrictions on the test class itself with regards to instance variables, language (i.e. Groovy), dependencies in outside packages, etc.  Why wouldn’t I want such flexibility in my test code?  I really want my test code to be as concise and expressive as possible, particularly as my apps get larger and more complex.  I think having alternative ways of approaching this kind of testing brings a lot of these types of benefits.

Update: I’ve added the controls to spin forward an backward, mouseover effects on the image and a simple onclick action.

I’ve been working on a spinner widget. "What is a spinner widget?" I heard you cry. If you’ve seen those flash widgets on Amazon that spin product images around in 3D, you know what I mean. I wanted to see if this could be done in pure DHTML. Well, it can, see image below and a demo here.

The widget uses projection geometry (a view point and calculating image size and position based on where lines pass through the z=0 plane) and a little bit of trigonometry for the circle. Also, zIndex is set based on an object’s z coordinate. At this stage the implementation definitely performs differently based on machine horsepower and browser platform. It performs pretty well on IE7 and Safari 3, less well on Firefox.

The implementation is in GWT 1.5 (built from SVN), but could be done in pure JavaScript (obviously). Next steps include direct manipulation of the spinner (drag to spin the circle) and drag and drop, response to clicks on images, the ability to spin arbitrary DOM elements, etc. Also, I want to squeeze some better performance by using an image strip (clipped with CSS). Stay tuned.

Technorati Tags: ajax, gwt, widget, 3D

I’ve long been a proponent of server-side Ajax frameworks — frameworks that store state on the server and use an Ajax engine in the browser to drive the display. The advantages: state and control logic stay on the server, so security compromises that exploit client-side state and logic are more difficult to pull off; developers can work in one language and, for the most part, ignore the fact they are writing a web application. The disadvantages: the server retains a large amount of state, so scaling your application can be problematic.

There’s one other large disadvantage to these open source server-side frameworks: for every 100 Java developers who use the framework, there is only 1 of them that can do serious JavaScript development. That means that the lifeblood of these frameworks — the development of new and cool JavaScript widgets — is sluggish at best. That has certainly been the case with the best known 3 frameworks: Echo2, ZK and ThinWire (though ZK does wrap a number of Ajax widget libraries, such as Dojo).

Test driven development has advantages all around– one of them being that it saves you time.  And what’s a good use of this time?  Why, coming up with novel ways of testing, of course.  I had one of those experiences the other day thinking of ways to go about profiling memory usage of a web application (by which I mean, the server-side component of a GWT-based application currently in development).

At it’s heart, the problem was simple enough: execute a few thousand service method calls with semi-random data, and see what happens to memory over time.  I considered writing a standalone Java application, or culling through existing testcases for some kind of integration test which provided enough coverage to be "interesting", and decided that what I really wanted to do was exercise the system through its front door.  I pulled out JMeter but soon had a realization: "we’re writing a GWT app.. why not just write another GWT app to exercise the same services methods as we otherwise do, but in a manner I need?"  So that’s what I did.

Dietrich observes the following at the GWT conference:

BTW, many of the developers at the conference seem to be Java geeks who resent their JavaScript brethren and don’t want to get left behind when the Ajax bus rolls down the corporate highway. They also applauded “hating the browser with all my heart.”

And…

about 100% [of attendees] had some background in desktop GUI’s, (AWT, Swing or SWT)

I don’t want to make to much of the sample size (most of the participants at Rails Edge were Java refugees, and I’d guess that, like me, a lot of them had desktop GUI experience). Still, this isn’t a surprise, right? GWT brings a Java desktop GUI programming experience to the web, if you are already a Java desktop GUI programmer, that’s very appealing. GWT is clearly great structure for bringing existing Java desktop applications to the web.

I always felt that one of the reasons why HTML and the web became so appealing was that the extremely low barrier to entry when compared to desktop GUI libraries. (This is one reason why first HTML and later, Flash, beat out Java applets — they were just much easier to write for the most common tasks.)

Despite HTML’s flaws as a layout engine, getting something on the screen is really easy. You don’t need to learn the entire Swing object model and event model. This isn’t exactly a fair comparison, I guess. But HTML’s biggest strength — managing variously styled text — is something that is a massive pain in the neck in most traditional GUI systems. That’s why so many toolkits have adopted a subset of HTML as a markup system for labels and static text.

It might be true that HTML just feels easier because most web application are, even now, less complex than desktop applications. Still, even as complexity increases, I’ve always found it much easier to manage layout in HTML/CSS than in Swing layout managers. I find that even easy layouts are hard to mange with any precision in Swing. I’ve been much more likely to wish that I had HTML or CSS kind of structures in Swing than I’ve wished for Swing layout managers in HTML. And that’s without even counting the fact that Swing, and GUI layout code in general, is notorious for being a tangled mess.

I still think, that there’s a middle ground between HTML and Swing — something like XUL or Flex, combining the best of HTML’s easy-to-get-started textual structure with the power of a full object system.

I took GWT’s history manager for a spin last week courtesy of the Kitchen Sink Example Project. Overall I was impressed; it worked flawlessly in a range of up-to-date browsers and operating systems. Then I decided to give it a try in the two browsers that caused me the most pain with Really Simple History: Safari 2.x and Opera 9.2x. The history implementation in each browser is deeply buggy; I resorted to lots of user-agent-specific hackery to work around it. GWT apparently doesn’t try.

In Safari 2.03 and 2.04, both of which RSH supports, GWT offers no back-button support. Hit a number of different history points in the kitchen sink app, then hit "back" and you’ll end up on whatever site you were on before you got there. Things in Opera 9.2x fail less gracefully. History points get created, but the back button doesn’t trigger GWT’s history listener. So if you visit five different history points within a GWT application, you’ll still have to hit your back button five times to get back to whatever site you were on before. Yet your application state doesn’t change as the result of any of those back-button clicks.

Having profited from the hard work of other history-manager authors and spent countless hours on my own implementation, I know exactly why both of these problems are occurring. When you change the hash value of a URL in Safari 2.x, the only part of its history object that gets updated is history.length. If you don’t key all of your history events and callbacks off the value of history.length, your history manager simply won’t work. As for Opera 9.2x, hitting the back button completely blows away all JavaScript timers. You have to get creative in order to re-initialize your history-change polling. Luckily, Safari 2.x and Opera 9.2x are on their way out. GWT’s history manager works as expected in Safari 3/Mac and Opera 9.5. (Safari 3/Windows is just as broken for GWT as it is for RSH; it’s just too buggy to hack around.)

The question of browser support in Ajax libraries is an interesting one. To what extent should a library author feel obligated to fight the good fight against buggy browsers – especially niche ones? RSH 0.6 would be a good 20% smaller – and have taken about 60% less of my time to develop – if I had opted to support only the latest and greatest betas of Opera and Safari/Mac. I even have a half-implemented feature to return an isSupported boolean upon initialization of my library. I haven’t gone further with that particular enhancement because once you go down the road of monitoring minor version numbers and changing your library to react to them, you’ve doomed yourself to constant maintenance. You’ve got to draw a line in the sand somewhere; GWT and RSH simply draw the line at different places.

Technorati Tags

• ajax
• javascript
• bookmarking
• GWT
• Really Simple History

So I’ve been blogging all this week from the Voices That Matter: Google Web Toolkit Conference. For those who requested a summary of my posts on various sessions, they are…

• GWT as a Replacement for Java Swing Apps
• GWT Pronounced "Gwit"
• Josh Bloch Intro Q&A
• Coming in GWT 1.5: Selenium testing support
• Bruce Johnson/Dan Peterson Presentation on Productivity
• GWT Security Talk
• GWT Performance Talk
• Chat with Bruce Johnson
• GWT App Panel
• GWT Conference, Day 2
• Deferred Binding with Ray Cromwell
• David Geary’s Cool and Useful Stuff
• Interesting Amateur Demographic
• Creating Widgets (or really, why GWT won’t leak memory)
• Bruce Johnson’s Tour of GWT Core Libraries
• Joel Webber on Architecture Best Practices
• GWT Tools Panel
• GWT Conference, Day 3
• Best Practices for Building Libraries
• Final Q&A

Really, there were three highlights of the conference for me, two of them reminders, and one of them a surprise.

1. GWT is a compiler. Let me amplify: it is a compiler, not just a Java to JavaScript converter. It inlines methods, removes dead code, optimizes loops, all those things that a compiler can and should do. And if you play by the GWT rules, you will not leak memory. Want a faster, smaller app? Wait 3 months and recompile with the newest version. Eventually, the compiler will produce better, more efficient JavaScript than you can produce by hand.
2. The security concerns for GWT are the same as for all sophisticated Ajax applications: the more state and control logic you put in the client, the more you open yourself up to really nasty attacks. In a sense, the fact that GWT makes writing sophisticated client side code so easy and obscures which Java code is in the client and which in the server, it can increase the potential for making these mistakes.
3. The surprise? The conference was not attended by that many GWT newbies or web developers looking to bring their Struts apps into the Ajax light. A show of hands brought home the fact that the audience consisted of mostly folks with Swing/AWT/SWT experience (though they also worked with webapps).

This last item made this the most unusual conference I have attended. Usually, when a technology is barely a year old, you expect the first conference to consist of newbies listening to the vendor and a few select clients talk about the technology and their early adopter experiences. If any of the attendees have written apps of their own, they suffer from all of the "version 1 on a new technology" problems, i.e. in version one you don’t have your model quite right, your UI is a bit off and fighting with your model, and you’ve brought other, inappropriate platform idioms to the new technology. With version 2 you fix all of the version 1 problems and introduce a bunch of new ones. With version 3 your model is pretty good and in harmony with your UI and you’ve started to introduce some framework code that makes you more productive.

Well, the folks at the conference were already past version 3 on some pretty slick desktop apps, and the resulting ports to GWT had even the GWT team scratching their heads and saying "wow, I didn’t know you could do that with a browser."

All in all, a very promising start to a conference. If year 2 improves on year 1 and adds a few more tool vendors, as I expect it will, I will definitely attend.

Technorati Tags: ajax, gwt

Just a sampling of some of the Q&A:

• Q: What is the direction of the ability to index (search) pages created by GWT? A: It’s a hard problem, sort of like indexing a Flash App.
• Q: Do you foresee building Android Apps with GWT? A: Ray Cromwell is working on making GWT work in Android (don’t use widgets, just JRE). See Ray’s blog.
• Q: How do you decide to prioritize feature requests? A: In the issue tracker, there is an ability to vote for features. More priority is given to things that effect a lot of people. Also, contribute to the things that matter to you in the incubator.
• Q: How does implementation inheritance fit into the design of GWT? A: We aren’t a religious bunch in terms of design (except user experience). As soon as you design something that can be subclassed, the arguments about private, protected, etc., start. It’s more trouble than it’s worth. GWT is a pragmatic framework. Let’s not confuse getting stuff done with over-architecting the solution. The answer to this is Interfaces (HasText, HasHTML) and helper objects.
• Q: 1.4 had a ton of stuff in it, 1.5 as well. Will you try to move to quicker, smaller releases? A: Quarterly is our goal with a few (two?) milestone builds in between.
• Q: What is the progress on Firefox 3? A: There is one big problem with FF3: has gotten more restrictive about adding DOM nodes to a document. Would affect you if you had written JavaScript by hand as well, only you would grep for appendChild() for the bugs.
• Q: How stable will the DOM structure of Widgets be (for CSS writers)? A: If they have CSS names, it is stable, if they don’t, they’re not.
• A call to fix the mistakes rather than being infinitely backward compatible.
• Q: Could GWT be used to build distributed computing environments? A: Interesting idea if you are willing to live with the limitations of the the browser (fuzzy numeric calculations, etc.). Try it.
• Bruce J Question: If we created collections for GWT that are more efficient (and provided them alongside the existing Collections classes), would people use that.
• Q: It seems I add styling to everything. Is this typical? A: It seems to be pretty typical (but also typical of other HTML development outside of GWT). ImmutableResourceBundle will allow programmatic access to stuff like CSS (in incubator). Should make resource problems easier and speeds things up.
• Q: StringUtil? A: If it’s translatable, you can use it.
• Q: Any plans to add setting opacity to DOM? A: Yes. Send Joel the issue.

BTW, Google is writing a 50,000 line GWT app (and another 50,000 on the backend) to allow radio stations to view the ads that they are putting on the air.

Technorati Tags: ajax, gwt