Archives

Scott Dietzen over at Zimbra has a post in a continuing series on AJAX scalability. Besides coining the humorous term "Husky" Client to describe AJAX — not quite thin, but not quite fat — he makes some excellent points about the importance of design and choosing the appropriate browser/server boundary for an application in order to minimize the impact on the server.

I thought the following early paragraph was a nice observation by someone who clearly has a bit of experience developing applications:

Traditional fat client applications, on the other hand, off-load all of
the UI and most of the business logic (modulo stored procedures and
triggers) from the server to the client. Fat client app’s could
nevertheless hammer their servers simply by not being sophisticated
about how much and how often data was being requested—that is, data shipping to the client can be more expensive than function shipping
to the server (with stored procedures, triggers, et al). With a
reasonably smart design, however, fat client applications typically use
more client and less server CPU per operation than a corresponding
server-centric application.

I think the generation of RIA’s (Rich Interaction Application) that are about to sweep the web are likely going to repeat many of the mistakes of the client/server age. As Scott points out, how poorly these applications perform is going to be in part dependent on how well they are designed. As Santayana wrote, "Those who cannot remember the past are condemned to repeat it."

Share/Bookmark

Our Elyse Sanchez has just authored an article entitled "Features into Flow: Techniques for Optimizing User Interactions." It distills some of our experiences designing software for educational reform in an Arabic gulf state. Some choice excerpts:

The success of our design methodology is dependent in a large part on user research and the creation of personas and task-based scenarios. Our principle Enumeration persona, Ahmad, spends a few weeks each autumn traveling through the desert from school to school, generally spending about a week at each location, where he has to manage with makeshift accommodations and associated distractions. A thorough and competent data collector, he dislikes making errors. Using his laptop computer, he enters his data very quickly but often struggles to meet his deadlines.

We were able to incorporate several strategies for optimizing flow and offering Ahmad the benefits of a “smart” application. First, we designed a linear, tabbed structure that guided the information-collecting process and ensured that all dependencies were correctly met (for example, information on teachers had to be obtained and completed before student information could be gathered). For selected subtasks, information had to be moved from one area of the display to another. To enable this in as few keystrokes as possible, we implemented a drag-and-drop function that greatly simplified what could have been monotonous, time-consuming data-recording tasks.

You can read the article here (pdf).

Share/Bookmark

How does the concept of flow manifest in an application? We usually look at three different aspects of flow during the design process.

The first is efficiency. Often we are seeking the use of an application to save us time in accomplishing what we have to do. In the user’s eyes, efficiency gains are often tied to satisfaction and are frequently where flow starts.

The second aspect of flow is hybrid navigation. Most applications of moderate or greater complexity will require a combination of linear and non-linear activities. It is important that the designer be able to empower each activity while keeping the overall scheme consistent and intuitive.

The third aspect of flow is comfort. When the interaction with a product is comfortable and natural, the product starts working at an emotional level. In technology-based products, accomplishing comfort in the design can be a significant differentiator in the marketplace.

Share/Bookmark

I gave my presentation last evening to a welcoming Chi2 audience. The attendees were a good mixture of developers, designers and business folks. They sat through my rantings on why I thought Rich Interaction Applications (RIA) in AJAX should be developed with server-side component based GUI’s, though, in a pinch, I could see the argument for client-side component based GUI’s that use the back-end as a dumb data web service. Then I showed them what 150 lines of Java code could do in the Echo2 framework with my special "why would you do things this way" stock quote app. Lot’s of dragging and dropping ensued.

I’ll put the presentation and the demo up when I get a chance.

One of the more interesting and probing questions after the talk was about business logic leakage, i.e. how does a server-side component GUI (SGUI) keep you from leaking business logic? The answer is simple: with the SGUI, the only "logic" that makes it to the browser is "turn this area blue," "move this button over here," and "make this element draggable." While I suppose it is possible to leak business logic in this way, I’d have to say that the possibility is pretty remote and esoteric, akin to sending smoke signals.

In the pseudo hand-coded world of traditional webapp development, you are dependent on developers following good practices and not making mistakes, such as leaking the secret sauce in their Javascript validation logic. At least you hope they do. If the last 50 years of software development practice have taught us anything, it’s that hope is not a plan.

There are two kinds of information leak — what and how. "What" is your customer data, your orders, your accounts receivable, your employee database. The "how" is your secret sauce, the special way of pricing or quoting or doing that gives you a competitive advantage. Reports can leak the "what," and many businesses can survive a leak of quite a bit of "what," but leak the "how," your secret sauce that makes you money, and you’re cooked. Javascript can leak the "how" if you let it.

Michael Mahemoff feels it’s sometimes OK to include business logic in the Javascript:

I realise there are plenty of problems with Javascript business
logic, and it’s certainly not always applicable. Those problems include:

• Security – Exposes business logic algorithms and enables them to be changed.

That first bit applies to most all valuable services that a company might provide. If all you’re providing is data, then no business logic would be leaked. If you are performing some sort of business logic on the data, it would have to be something pretty trivial to still have value and not be a divulging of the crown jewels. Can a business consist of a bunch of ultra trivial, obvious logic and still be competitive? Probably not. In short, I can’t imagine the circumstances where that first item wouldn’t just preclude exposing most any business logic.

Share/Bookmark

"Flow" is an attribute we’re talking about–and, hopefully, designing towards–here at Pathfinder. As application designers, we’ve been captive eyewitnesses to the proliferation of contradictory and unrelated features that consititues progress in IA and development.

Design theories of flow are derived, directly or indirectly, from the work of psychology professor Mihaly Csikszentmihalyi, who has dedicated over two decades to developing a theory of "optimal experience."

We’ve recently shared some of our thoughts on flow at the IA Summit and World Usability Day. Other perspectives include those of Kathy Sierra, the academically focused ACM, and designer/blogger Scott Berkun.

Plus, an interview with The Man Himself in Wired, titled (you guessed it) "Go with the Flow."

Share/Bookmark

There have been some interesting experiments in breaking the bounds of the rectalinear forms-and-reports browser interface. One example,  John Resig’s dModeler, is a cut at a UML class modeler. In his words it is:

A web-based UML
modeling program that my team wrote for the 4th Red Bull Programming
competition. We weren’t able to complete all that much of it, but we
did get creation of classes, links, drawing, signups, logins, and
parameter creation finished. At some point it may be fun to sit down
and modify what we wrote and get it fully operational and possibly
release it.

There’s no AJAX logic behind it to provide any logic or even persist it, but I encourage folks to look at it that you can provide rich client functionality in the browser. Think outside the grid.

Update 1: you may need to use Firefox to get this to work. Ironically, it was designed to work with IE, but the login has some Javascript errors. Firefox will blissfully ignore the logins and get you to the diagram.

Share/Bookmark

As if choosing between different BRE vendors wasn’t tough enough, there’s an added consideration: is the problem you are trying to solve more amenable to a forward or backward chaining approach? Forward chaining, which is the default behavior of most commercial and open-source rule engines, is described as

An inference engine using forward chaining searches the inference rules until it finds one where the If clause is known to be true. When found it can conclude, or infer, the Then clause, resulting in the addition of new information to its dataset.

while backward chaining is described as

An inference engine using backward chaining would search the inference rules until it finds one which has a Then clause that matches a desired goal. If the If
clause of that inference rule is not known to be true, then it is added
to the list of goals (in order for your goal to be confirmed you must
also provide data that confirms this new rule).

So in other words one approach starts with some facts and applies rules to find all possible conclusions, the other starts with the desired conclusion(s) and works backwards to find supporting facts. You can sort of view these approaches as two variations on search, with each step forward or backward forming a tree, either spanning out forwards towards conclusions or spanning out backwards towards initial facts. In point of fact, most rule systems don’t go about finding all possible branches in this tree but use some sort of planning or goal setting to guide their search.

What are the advantages of one approach over the other and when would you use each? As it turns out, they can both solve the same problems. Most computer science students have to show at one point in their studies that any backward chaining rule system can be rewritten as an equivalent forward chaining system. Showing the reverse isn’t quite so easy, but can be done in a graduate course. So both forward and backward chaining approaches can solve the same problems, but they have somewhat different performance characteristics, and certain problems are much easier to express in one or the other. Charles Forgy put it very succinctly in one of his articles on backward versus forward chaining (sorry, no link. The articles don’t appear to be available now that Rulespower has been acquired by Fair Isaac)

You might ask why you would want to use a forward chaining system if you have to write rules to manage subgoals. After all, backward chaining systems automatically manage the subgoals. There answer is very simple: Backward chaining systems are more limited than forward chaining systems. There are many kinds of tasks that can be handled easily with a forward chaining system that are either difficult or impossible with a backward chaining system. Backward chaining systems are good for diagnostic and classification tasks, but they are not good for planning, design, process monitoring, and quite a few other tasks. Forward chaining systems can handle all these tasks.

So, if you already know what you are looking for, e.g. a customer that might be committing fraud, a patient at risk for breast cancer, etc., then backward chaining may be a good solution. On the other hand, if you don’t necessarily know the final state of your solution, e.g. improvements to a business process, suggesting next steps in a due diligence investigation, or directing data transformations in an ETL process, then a forward chaining approach my be preferrable.

On the design front, backward chaining product will often have better justification or explanation mechanisms, i.e. explanations on how you arrived at a particular goal. If this is important to you, as it might be if you are working in clinical medicine, then a backward chaining solution might be a good fit.

On the performance front, there are certain circumstances where backward chaining might be better. For instance, if you have a small number of rules and a huge number of facts, you might be able to lazy load only those facts that are relevant to fulfilling goals.

If you’d like to play around a bit with a backward chaining rule engine, give Mandarax a try. Also, some commercial BRE’s provide backward chaining as well as some other rule execution algorithms.

Feeling pretty good about your grasp of backward and forward chaining? Did you know there are hybrid approaches that combine both backward and forward chaining? Yep, it’s true. But we won’t go there today.

Share/Bookmark

It seems the evolution of games that happened on the PC and on-line is repeating itself in the AJAX arena. First come the board games — see Ajax Chess, 64Pola, and Morfiks — and the muds — hive7, then the low fidelity arcade games, then the first person shooter games. Is AJAX Doom too far away? Yeah, probably.

The chess games are actually pretty lousy, more experiments in Ajax rather than real apps. I’ve written a few chess games in my time and will take a crack at one that incorporates back-end access to a chess engine. Why reinvent the wheel? Just expose a FEN web service wrapper over a winboard engine like crafty.

The truth is that for the first person shooters and other higher perf stuff, flash is better than AJAX based apps are likely to be (See here for everything from Doom to WarCraft to Mortal Kombat in Flash). In truth, if you scratch below the surface a bit, what differentiates something like Flash and Java Applets from AJAX for any sort of application is the install and startup overhead. OpenLaszlo can communicate with the server just fine, thank you, and Java Applets have been able to do that since the beginning. So why all the hype over AJAX now?

Now that it’s all wrapped into the browser, it seems tempting to move to AJAX. It’s already in there, so they can’t resist like they can with Flash and Applets. What are they going to do, turn off Javascript?

But for everyone from those developing public facing to intranet apps, there’s reason to look beyond the buzz of AJAX. If you’re making the move to interactive, rich client user experience, is AJAX really the right choice? Do you trust your Ajax framework vendor enough or do you have deep enough pockets to keep your apps up-to-date with the changing browser landscape? Is the kind of rich client experience you are after achievable with AJAX? Why didn’t you go with the other technologies in the first place and settled on a forms-and-reports conventional webapp instead?

Go over your reasons again or you may find yourself implementing Doom in AJAX.

Update 1: pitstreet.com has an assortment of Javascript games, including some that employ AJAX. Their usability leaves something to be desired. Just try to find the chess or reversi games.

Share/Bookmark

Since my rant started flowing, I just thought I’d pull this out of the comments section at Ajaxian.com:

Beyond becoming multi-threaded, AJAX is beginning to open up
the web to new types of applications, ones that are document centric
(word processors, modeling tools, etc.) rather than data and
transaction centric, i.e. all those rectangular CRUD applications that
make up 99.9% of webapps. It also means that the sorts and types of
rich client interactions are going to dwarf the traffic that we see
today.

That means 1. abandoning the forms-and-reports way of
writing webapps (which will break when you try to write something like
rational rose as a webapp) and moving to the component GUI model (like
Swing, Winforms, etc.) and 2. being very clever about the frequency and
size of your XHR conversations with the server. From my unscientific
tests (Yahoo mail and Google calendar)
it seems that some are winning and some are losing the battle on fat
XHR. I don’t think any amount of JSON or compressed XML magic will
solve the problem of poor design.

I think the right way to
achieve all of this is by moving AJAX/Webapp development to component
GUI application frameworks. Properly done, they have the potential to
hide all of the messy bits like exposing too much of your business
logic on the client side, optimizing XHR requests for components that
have empty server-side event listeners, reducing the impedence mismatch
between the Javascript/CSS/XHTML world and the business logic.

Those
who don’t move in this direction will be stuck building and maintaining
ever more complex applications because they didn’t make the shift to a
new design. It’s time to think of the browser simply as a display server.

Share/Bookmark

X11 is a client/server display system that realizes user interfaces by sending asynchronous messages back and forth between a display server — that manages a display, mouse and keyboard — and clients such as xterms, Firefox, GIMP, etc. Some of the drawing, windowing, events and other operations that the X protocol supports look suspiciously like some of the things flying around in Ajax these days.

Now there are some substantial differences between X and Ajax. For one, X clients (the equivalent of the http server) open up persistent connections to the X server (the equivalent to the browser), while the ‘Ajax server", aka the browser, has to poll the "Ajax clients" (the apps on the http server) for messages. X is typically used in a LAN rather than a WAN setting, for this reason. Persistent connections usually don’t hold up very well in a WAN context. Also, there’s no embedded scripting language like Javascript in X.

One definite similarity is that both X and Ajax don’t have any widget standards. In X you’ve got several different widget sets — Motif, Qt, Gtk, etc. — while in Ajax you’ve got a few early frameworks with their own widgets.

So, what’s to be learned from all of this? First, while user interfaces may well head in the component GUI/widget directions, we’ll likely have quite a number of different widget sets in the long run. Second, there are a few design lessons to be learned from X Windows. For example, the creation of windows with a specific look and feel is controlled by a window manager abstract factory.

Some of these design solutions may not be appropriate for Ajax, but I think it’s worth mining this trove of design solutions. Might we some day have an Ajax desktop that unifies multiple independent Ajax applications?

Update 1: Bill Scott makes a similar point (though much earlier — more coffee, I’m sure).

Share/Bookmark