Thoughts on Jon Udell's Infoworld column on Rich GUIs... How rich, really, is that rich GUI we nostalgically crave?

What I crave, seeing developers on projects recreating significant portions of windowing systems in HTML and Javascript, what I crave is the ease of developing those rich GUIs.

When tabs appear in multiple rows, they create a problem that Jeff Johnson, author of the wonderful book GUI Bloopers (infoworld.com/453), calls "dancing tabs." Clicking on a tab not in the front row disconcertingly reorders the rows. On a Web page controlled by rows of links, that doesn't happen.

These complex interactions I think are as much of an indictment of the model as of the view. Our systems require a lot of dials, or seem to.

A GUI that doesn't embrace linking can never be truly rich.

When I think of truly rich GUIs, two classics come to mind, Hypercard and Emacs. Each exceed the restrictions of the Mac 128k GUI which we are otherwise pretty much bound to for now, albiet on 17 inch monitors.

Both of these systems featured hypertext and flexible navigation well before HTML and HTTP. Both creatively avoid the keyhole problem.  ¶ 6:38 PM

Any thoughts on creating a .NET language targeted at "occupational" programmers i.e. folks that aren't programmers but need to essentially encode/automate an algorithm, run it repeatedly and store the results? I would think this could be a great addition to VSA where an admin assistants with no formal programming training might be able to write a small program to automate a task in an Office app.

Here's a suggestion from the 1970s...

Multics Emacs proved to be a great success -- programming new editing commands was so convenient that even the secretaries in his office started learning how to use it. They used a manual someone had written which showed how to extend Emacs, but didn't say it was a programming. So the secretaries, who believed they couldn't do programming, weren't scared off. They read the manual, discovered they could do useful things and they learned to program.

Here's another idea that was demonstrated in the 1970s...

In 1972 Kay took a job at Xerox's Palo Alto Research Center (Xerox PARC) and began using Smalltalk in an educational context. Young children were exposed to computers and their reactions were analyzed. Kay concluded that children learned more through images and sounds than through plain text and, along with other researchers at PARC, Kay developed a simple computer system which made heavy use of graphics and animation. Some of the children became very adept at using this system; in fact, some developed complicated programs of their own with it!

Yes, I think (no surprise) it would be great if the newest "managed runtime" could manage decent support for the longest-used and most proven "managed runtimes"!   ¶ 6:56 AM

Don Park wants a standard place, er, places plural, for a site's metadata. Since I seem to be grouchy already this morning, I will apply my bad mood to this idea...

I think it is absurd to try to agree on where to put "metadata" before agreeing on what the "metadata" is.

Please lead the way to save me the headache. And get the tool builders to build it for me. And then use it for a couple years so I can determine the ROI.

Thanks.

My feeling is if "metadata" is not self-generating then it has relatively little value. For example RSS is valuable "metadata".

Curiously, though, Don writes in the comments section...

I don't think .w3c should know anything about RSS. It should just be a bag of links or inlined metadata along with some useful info to help agents find what they are looking for without wasting bandwidth unnecessarily.

I am all for standardizing worthwhile metadata structure and values, where "worthwhile" is the crux of the matter. So I am more than a little surprised that this vague proposal apparently is to remain ignorant of the most significant self-generated "metadata" on the web today. Not to mention that this kind of metadata (RSS) is fractured already into multiple names, locations, and contents.

IMHO any such metadata effort should be *primarily* focused around RSS and its cousins.  ¶ 6:21 AM

I'm looking through the javadocs for the Rain project from Intel Research. What might be of interest to the growing discussion about continuation-based web servers?

Here's what... Continuation.java

This class provides a mechanism to continue a computation after a reply to a message has arrived. This works by associating a continuation with an outbound message using the associate method. When a reply to this message arrives, the service calls the invoke method on the continuation object. If the continuation was constructed with a timeout and a reply does not arrive within that time, the timeout method will be called. While this class is not abstract, it does very little of interest until either invoke , timeout or both are overridden.

By default, continuations are "single shot". This means that once a reply has been received, the continuation is removed from the continuation system. To create a continuation that can be invoked by multiple replies to a message, call setMultiShot with true. (Multi-shot continuations are useful in situations where multiple replies may come back for a single sent message.) Note that a multi-shot continuation with no timeout won't ever expire, so do not forget to remove them with the delete method.   ¶ 10:23 PM

I'm just back from Brett Pettichord's talk on Four Schools of Software Testing at the Portland SPIN meeting.

I don't know much about the context-driven school, but I am curious since Ward Cunningham is enthusiastic about these "young turks of testing". Brian Marick was there and participating in the Q&A too.

I think there is a good book to be written on "Planning Context-Driven Testing". I can see that one could come away from an initial discussion with impressions (prejudice) from the "old school" testers that context-driven means "unplanned". This is based on my observations of "old school" reactions to the agile movement of software development.

After Brett's talk, Brian explained in a small conversation that a way he plans for testing is to look ahead at all the potential hand-offs of software between people. (There are many kinds of hand-offs: from programmer-to-programmer, and so on, including handing off to the end user.) I really liked this approach.  ¶ 8:50 PM

I was asked for my Top 5 books on object-oriented programming. In no particular order, this is what I came up with...

• Robert Martin's DOOCAUTBM
• Design Patterns
• Refactoring: Improving the Design of Existing Code
• Kent Beck's Guide to Better Smalltalk: A Sorted Collection
• Concurrency: State Models & Java Programs

But ask me some other day and there might be other titles in the list.   ¶ 11:00 PM

Phillip Windley writes about early web service adopters, hits many right notes, and some wisdom for moving forward. The only note that doesn't really sound right is about the past:

I'm still trying to figure out how this is different from the world of 3-4 years ago when there were no standards for decentralized computing.

Three to four years ago, CORBA was a standard for decentralized computing. The core had matured, interoperability was well underway, firewalls were being tunneled, and less expensive and open source implementations were coming to market. Real-time issues were being overcome.

Moreover, the core remote procedure call mechanism was being enhanced with asynchronous messaging and 3.0's improvements were on the drawing boards if not in the implementations, including a cross-language improvement on the Java-only EJB server architecture.

CORBA is not web services, but they are so much more alike than they are different.

Except when it comes to maturity, the early adopters are now grey beards.   ¶ 10:36 PM

Jon Udell writes about the front-end and Phillip Windley writes about the back-end of web services.

Adam Bosworth also writes about the front end.

There is a client/server feel to this new web services architecture. I don't believe that is anyone's intention, just my perception, because of what's not being described.

Is something missing? I have not quite put my finger on what that is. What is the "middle tier" of a web services architecture?

Here are some thoughts on a component architecture, where components are pieced together in many-many-many relationships for some solution...

• Front - not a browser but browsing/transacting purpose-based component(s), e.g. outline, calendar, form.
• Middle - application-specific aggregating component(s), e.g. work flows (state machines), sorting, searching, tallying.
• Back - OLTP and OLAP data service(s), e.g. the transaction engines for and historical sources of domain knowledge.

The other pieces that are still missing for me are even more central... the priority use-cases and funded evolutionary paths that would drive these visions.   ¶ 9:21 PM