Archives

Believe it or not, it’s paper. It’s not often regarded as a power tool, but when it comes to complex thinking and problem solving, paper is often as ubiquitous as water and air.

Edward Tufte points out in a posting on his site that “in the last 10 years, every country in the western world has increased its per capita use of paper.” I know I’m doing my part, and my co-workers as well.

For more reading on paper and its uses in thinking and cognition, check out the posting by Tufte on his web site. 

Share/Bookmark

In a comment to my post Friday on cognitive load and the supperiority of server-side AJAX GUI frameworks, reader Matt took me to task for muddling my tiers:

I would argue that mixing the middle tier (java) with the front-end (javascript, html, css) is the same as mixing the middle tier with the backend (db). In general, it is bad practice. Sure, some companies still directly access the db from inline sql, but the majority of developers agree it is bad practice.

While I agree with Matt that if you’re going to adopt a layered architectural approach, you don’t want to mix different subtasks into the same layer, simply putting code into the same physical environment or writing it in the same language does not constitute mixing layers. Rather than blindly following the “tiered approach,” it is helpful to look at the original patterns source and understand its purpose. The first time I saw a formal discussion of the layered architecture pattern was in 1996 in the very useful Pattern-Oriented Software Architecture: A System of Patterns, Volume 1 by Frank Buschmann et al., Chapter 2, Section 2.2: From Mud to Structure. (Funny how some patterns in that book gained huge popularity, such as MVC, while more elegant patterns, like Presentation-Abstraction-Control, gain barely a mention.) From the text:

The Layers architectural pattern helps to structure applications that can be decomposed into groups of subtasks in which each group of subtasks is at a particular level of abstraction.

[snip]

The main structural characteristic of the Layers pattern is that the services of Layer J are only used by Layer J + 1-there are no further direct dependencies between layers. This structure can be compared with a stack, or even an onion. Each individual layer shields all lower layers from direct access by higher layers.

[snip]

Specify an interface for each layer. If Layer J should be a ‘black box’ for Layer J+1, design a flat interface that offers all Layer J’s services. and perhaps encapsulate this interface in a Facade object [GHJV95]. The Known Uses section describes flat interfaces further. A ‘whitebox’ approach is that in which Layer J+1 sees the internals of Layer J. The last figure in the Structure section shows a ‘gray-box’ approach, a compromise between black and white box approaches. Here Layer J+1 is aware of the fact that Layer J consists of three components, and addresses them separately, but does not see the internal workings of individual components.

Good design practise tells us to use the black-box approach whenever possible, because it supports system evolution better than other approaches. Exceptions to this rule can be made for reasons of efficiency, or a need to access the innards of another layer. The latter occurs rarely, and may be helped by the Reflection pattern, which supports more controlled access to the internal functioning of a component. Arguments over efficiency are debatable, especially when inlining can simply do away with a thin layer of indirection.

The first observation I have is that writing our code all in Java still allows us to adopt a layered approach. The UI code can be nicely abstracted from the business layer, as people have been doing now for decades. Just because we are writing both in Java doesn’t mean we are mixing the tiers.

The second observation I would make is that there is some confusion over which is the highest tier in web applications. As it’s usually illustrated in architectural diagrams, the presentation tier sits on top. Certainly that’s the way the end user sees it, and you can make an argument that that is how interactive applications should be architected, with the presentation tier using the services of the next tier down. I’d suggest a further refinement, one that’s been creeping into web applications and various frameworks: the rendering tier. That’s where the details of the underlying user interface device are abstracted as a set of functions for use by the presentation tier. That’s precisely what Echo2 does, hide the details of HTML, Javascript, CSS, etc., in a rendering layer.

Although no other rendering implementations exist at present for Echo2 and ZK (another server-side framework), they are perfectly positioned to add support for Flash, mobile, desktop and other user interface devices.

So, my response to Matt is that we aren’t mixing layers here, but — staying true to the original intent of the architectural pattern — improving the design of web applications by abstracting the details of the browser into a lower level rendering tier.

Technorati : ajax, cognitive load, complexity, layered architecture, patterns

Share/Bookmark

SecuirtyFocus has a decent article entitled Ajax Security Basics. A sample:

A second challenge relates to the difficulty involved in securing the increased attack surface. Ajax inevitably increases the overall complexity of the system. In the process of adopting Ajax, developers could code a great number of server-side pages, each page performing some tiny function (such as looking up a zip code for auto completing a user’s city and state fields) in the overall application. These small pages will each be an additional target for attackers, and thus an additional point which needs to be secured to ensure a new vulnerability has not been introduced. This is analogous to the well known security concept of multiple point of entry into a house: the difficulty involved in securing a house with one door as compared to securing one with ten doors.

Good basic explanation of Ajax, and the new security vulnerabilities it exposes. The article also points out some pitfalls for current webapp testing methodology:

Applications may periodically send requests to the server to update information on the web page. For example, a financial application may use the XHR object to update parts of the web page that display current stock market information. The tester may not be aware of this process happening in the background if they do not catch the request at the right time, since there may not be visible links or buttons to suggest to the tester that there are requests being made in the background.

Well worth checking out.

Technorati : ajax, security

Share/Bookmark

Noovo has a preview of their new Ajax home page editor available. From their blog:

Noovo is an Ajax-based web application for homepage editing and we will also provide hosted homepage service as well. During the demo phase, only main features of editor are available. You may get a hint as to what kind of service we have in product plan if you look at the top menu. Those features for hosted homepage service will be introduced here before long.

The fact that there are no user interface or usability guidelines in the Ajax world is apparent from the claustrophobic toolbar and somewhat unusual behavior of some of the controls. So, powerful but clunky.

Technorati : ajax, application, home page editor

Share/Bookmark

On his blog Accessites.org, Tommy Olsson describes two approaches to designing a web page, the Visual and the Structural.  Although the article is mostly about how designers and developers have different workflows, in it he goes on to say that among other things…

Visual designers see a web page as an image: the colours, shapes and images define the page; the content is something that populates the various areas of the image. This is a design-centric view

This strikes me as a poor understanding of Visual Design.  Any Designer worth the paper he sketches on should know that Visual Design can only work as a part of a system; thinking in terms of colors and shapes before content and structure is a recipe for a poor design.

The Article

Share/Bookmark

Back in 1993, the professor I was working for at the time won the Nobel Prize in Economics. Articles were published about him in many languages and he asked me if I would translate one from German into English. “I know German and English,” I thought to myself, “piece of cake.” I sat down with a German-English dictionary at the console of my Sparc-10 and inside of two hours had the translated article finished and a huge headache pounding in my brain. Keeping two paragraph and sentence structures in my head and trying to juggle the conections between them turned out to be a hellish task. I don’t know how those UN translators do it.

As it turns out, I’ve been performing a similar juggling act since that time, from the first CGI/HTML form pair that I wrote to the multi-tiered J2EE beasts that my company develops today. It’s not unusual for a developer to have to juggle Java, Javascript, XHTML, CSS, ActionScript, SQL and several different dialects of XML for a single use case. Each of these is a different language (though different from a natural language like German or English) and requires remembering seperate concepts and then remembering the connections between these concepts in each language context. It’s enough to give you a headache.

Cognitive Load

But why do we get a headache? Back in the 1950′s, a professor of Psychology named George Miller observed that the average human being could retain seven items in short term memory, plus or minus two items. When we work with ideas or concept in any sort of analytical thinking, we run up against this limitation again and again.

John Sweller, a professor of Education, came up with the idea of cognitive load in the late 1980′s. The basic idea was that your ability to learn and problem solve was limited by your short term memory. If a particular learning task required keeping track of many concept at the same time, it is said to have a high cognitive load and as a result you don’t learn as well or as easily. In fact, in analytical tasks like doing complex arithmetic, it can increase the rate at which you make errors. There’s a whole body of literature on cognitive load, cognitive stress, etc. Applied to our example of web application development, we see that juggling all of those different concepts in different programming and markup languages and runtime environments in our head, creates a high cognitive load, increases our error rate and impedes our ability to problem solve.

Usability is Not Just For End-Users

When we think usability, we usually think application user interface. That’s the stuff our clients end up using. But API’s and programming languages can also be more or less usable. API’s that have many method calls with seven or eight or nine parameters are a lot less pleasant to use than those that have method calls with one or two parameters. In Object Oriented programming, we use certain principles like abstraction, encapsulation, or the Facade pattern because we say they lead to good design. They also have the effect of decreasing the cognitive load of a design, allowing us to solve programming puzzles while keeping fewer concepts in our head.

Consider now a server-side Ajax GUI framework like Echo2; it allows you, for the most part, to write in one language — Java — and avoid having to juggle the client and server-side states in your head. If it doesn’t make a webapp development team many times more productive than a multi-context J2EE approach, I’ll eat my hat. Yet another reason to try out Echo2.

Technorati : ajax, cognitive load, memory, software development

Share/Bookmark

Apollo was announced by Adobe back in March of 2006. What is Apollo? From the Adobe Apollo official FAQ:

Apollo is the code name for a cross-operating system runtime being developed by Adobe that allows developers to leverage their existing web development skills (Flash, Flex, HTML, JavaScript, Ajax) to build and deploy Rich Internet Applications (RIAs) to the desktop.

[snip]

While a number of more traditional desktop applications can be built and targeted at the Apollo runtime, Apollo is targeted at making it easy to develop and deploy Rich Internet Applications to the desktop.

So, Flash without the browser? Actually, its a little more than that. It’s supposed to have a full featured API that allows you to interact with the underlying OS (Windows XP and OS X at this point). It also appears that some fairly low level programming is possible:

Apollo 1.0 will not have built in support for communicating directly with databases. However, it will be possible to write Database drivers in ActionScript (leveraging binary or XML sockets), which would allow Apollo applications to communicate directly with a database (both local and remote).

It seems like this is the “browser without the browser” in a JVM like package that users install on their PC’s and Mac’s. Developers can distribute Apollo based apps much like Java applications are distributed today, depending on the presence of the previously installed runtime. The runtime is a natural continuation of the development of the flash platform, which started out in Flash 2 with simple commands and has evolved into a second generation byte code VM with JIT compilation. Apollo looks to extend that platform and allow a tighter integration between the HTML/Javascript part of the runtime and the technologies that keep the lights on at the Adobe headquarters in San Jose — Flash and PDF. No more need for a Flex/Javascript bridge.

What’s in the API? From a presentation by Adobe:

• Offline / Occasionally Connected
• Applications can run in background
• Network
• • HTTP
  • XML-RPC / SOAP / Rest based web services
  • Binary and XML sockets
• File I/O
• Local storage / Settings API
• Custom Chrome

Still a little nebulous, I know. I find the offline/occasionally connected support very intriguing, but right now its just a tease.

Apollo may well be successful where Flash has struggle to gain acceptance in the past. As Ajax drives acceptance of rich interaction web applications, it is helping Flash along. If Apollo is seen as a better or cleaner way of deploying Ajax applications, or even as just another viable target for existing Ajax frameworks, that should drive it’s adoption. Still, Ajax prompts me to ask lots of stupid questions: how is this different from client-server; why not just use Java/Swing; why run desktop style apps in a browser; what’s wrong with Flash?

There are a few open questions for Apollo. For example, ActionScript 3 eliminated eval(), i.e. you can no longer include dynamically generated ActionScript. Since some Ajax frameworks and techniques load Javascript at runtime (JSON, etc.), the lack of a ECMAScript eval() is going to be a problem. According to the above presentation, ActionScript and Javascript will coexist within the environment, so maybe there will be an eval() in the one but not the other.

Apollo is slated for prerelease in the second half of 2006 (any day now) so we’ll have an answer to some of our questions soon.

Technorati : adobe, apollo, flash, runtime

Share/Bookmark

I’ve been using Google Maps for Mobile for a few weeks now and find it rather useful, especially when I’m in a strange city driving a rental without a nav system. OK, what does this have to do with Ajax? Nothing. And that’s precisely the point. Google, arguably the pioneer in all things Ajax, is distributing their Maps application — the Ajax app that first made people sit up and take notice — to mobile devices as a Java application.

Now maybe under the covers it’s actually a custom web browser that supports Ajax, (if anyone has taken the time to test this theory out, please let me know) but I somehow doubt it. What does this say about the state of mobile Ajax if the big dog on the block puts their money down on a custom Java application? I think it means that we’re a long way away from practical mobile Ajax and even further away from the winners being picked.

That of course doesn’t prevent Nokia and Opera and various other players from claiming that they’ve solved the mobile Ajax puzzle. Until they solve the problem of direct manipulation, though, they haven’t convinced me. Once Opera Mobile allows me to drag Google Maps (the non-mobile kind) around on my phone’s screen, they haven’t passed the Ajax version of the Turing test.

There are just too many interfaces for mobile devices now to make this practical. How do we support in an Ajax capable browser the buttons, pens and wheels that make up the beastiary of mobile device user controls? It’s not just about filling out forms anymore. Some phones may never be Ajax capable for this reason: their controls are just too limiting.

So, don’t hold your breath on mobile Ajax. By the time everyone has upgraded their phone, it’ll be 2008.

Update 1: I guess some people didn’t get the point of this post, and I do admit that I might have burried the lede. So let me try again: Google isn’t placing a bet on mobile Ajax. Mobile phones continue to have diverse user controls unsuitable for direct manipulation, which seems necessary for the Ajax version of Google Maps. The next generation of phones (RAZR, etc.) may not have the kind of pen interfaces to support that style of interaction. Therefore, mobile Ajax won’t be a reality for quite some time, maybe not even 2008. It’s not the software, but the hardware, and that’s why google is crafting a seperate app for each phone.

Technorati : ajax, gmm, google maps, java, mobile

Share/Bookmark

Mark Proctor of the JBoss Rules team gave me the heads up about an interesting debate (here and here) about First Order Logic (FOL) and whether various BRE’s do or should support it. One question that has come up is whether BRE’s can still be said to be Turing Complete? Actually, the two questions — whether a BRE supports FOL and whether it is Turing Complete — are quite seperate.

Turing Complete

First the easy question: when is a system Turing Complete? From the Wikipedia:

In computability theory, an abstract machine or programming language is called Turing complete, Turing equivalent, or (computationally) universal if it has a computational power equivalent to (i.e., capable of emulating) a simplified model of a programmable computer known as the universal Turing machine. Being equivalent to the universal Turing machine essentially means being able to perform any computational task – though it does not mean being able to perform such tasks efficiently, quickly, or easily.

So, what is a Turing machine? Again you can look at the Wikipedia, but in a nutshell, it’s a tape with an infinite number of cells, a read/write head, a finite alphabet that the head can write to a cell, a finite number of ‘states’ that the machine can be in, and a finite number of rules that say things like “if you are in state 3 and the symbol on the tape is ’0′, the write a ’1′, move the head one cell to the right and change your state to 8.”

While this may seem like a silly sort of machine (just try to write a word processor with it), it can do anything, given the right number of states and the right set of rules, that a von Neuman style of computer — essentiall the sort of computer with which you are reading this blog — can do. It’s handy for proving certain theorems about computability and complexity. If you can write any Turing machine with your device, then it is said to be a Universal Turing Machine, i.e. if you can compute it with an algorithm, you can do it with your machine. It should be obvious that a BRE, even without First Order Logic, is a UTM. We can have a fact that tells us what our state is, another fact that tells us where our read/write head is, a set of facts that represent all of the cells we’ve seen so far, and our rules that govern how our state, head and cells are modified. Therefore a BRE is Turing Complete.

Of course there’s a small fly in the ointment. Up above we said that a turing machine had an “infinite” number of cells. Of course your computer can’t accomodate an infinite number of cells, since it has a finite amount of memory and storage. This is a rather important point, as it turns out. Anything program running on a modern computer with finite memory and storage is at best a Finit State Machine, basically the most primite of the interesting algorithms. But in principle, a BRE with infinite memory is Turing Complete.

First Order Logic

I’ll try to stay a little non-technical here, mostly because all of my math text books are in storage. First Order Logic (or First Order Predicate Logic) is an extension of regular propositional logic with the addition of the universal and existential quantifiers. That means we can write conditions in our rules that are true for all facts of a particular type in our fact base or which are true for at least one fact. I’ve written before why having First Order Logic built into your BRE is a good thing. In short, you can work around your BRE not having it, but you’ll lose the performance advantage of your rule execution algorithm in the process, such as RETE. And there are plenty of scenarios where you are looking at an event history of a customer or client that call for FOL.

You can see, however, that our simulation of a Turing machine above never called for a quantifier. Thus even a BRE without FOL is Turing Complete (if it has infinit memory, yada yada). I hope this explanation I hope this entry has been useful and not too geeky. Behind all of the hype behind BRE’s, it is sometimes useful to understand what exactly they are and what they can do.

Share/Bookmark

A few weeks ago I put together a BJAX example using Greasemonkey (BJAX = Browser Extensions and AJAX). The idea behind BJAX, of course, is that you can use AJAX widgets on third party sites and do cross domain scripting with ease. Two examples of BJAX apps are Book Burro,

which will get you book prices from competing retailers, and MyStickies,

Which will let you put stickies on pretty much any web site and use them on any computer where you have the MyStickies plugin installed. These BJAX applications go quite a bit beyond the original intent of Greasemonkey. They don’t just enhance a few link but rather let you insert little mini-applications into someone else’s webapp. This is potentially very disruptive to site owners, as they can no longer control their message. Amazon and Barnes and Noble can’t be happy that people can seamlessly comparison shop, and the upcoming shareable feature of MyStickies could reduce the ability of community sites to moderate their own content.

My own BJAX application was built just for demo purposes in response to all the people who asked for a concrete example and thus wasn’t particularly useful. It put the current weather in downtown Chicago, updated every minute, in a translucent box and floated it over the google.com search page. I decided to update it so it worked both with Firefox and IE and could run in the Greasemonkey clone for IE, Turnabout (get the advanced version, otherwise you won’t be able to load your own scripts). The new, updated script can be found here. Three things have changed. Two of the changes are merely dealing with cross browser xml parsing and event handling. The third change is that clicking on the box now will toggle it from maximized to minimized.

Next steps are to port a client side AJAX framework so it uses GM_xmlhttpRequest, can handle being loaded after the page loads in Greasemonkey’s sandbox, and doesn’t have namespace conflicts with other AJAX frameworks. The mind races. Could GWT be adapted to build BJAX applications?

One potential issue with Greasemonkey and BJAX is that Greasemonkey runs after the page has loaded and all of the page’s Javascript has run. What will happen with a true AJAX application that controls its DOM much more closely. Could our inserted DIV get deleted or munged? Should Greasemonkey fire after every DOM update or XMLHttpRequest?

Update 1: Johan Sundström takes me to task for being lazy. I’ve changed the test for GM_xmlhttpRequest to

typeof GM_xmlhttpRequest != 'function'

Technorati : GM_xmlhttpRequest, bjax, firefox, greasemonkey, ie, javascript, turnabout

Share/Bookmark