Programmable Web

This is what people in the know call the next step in web evolution. What does this mean for us programmers? Well, it means a simplifying of server function. More accurately put: it means server portions of applications will need to specialize around the data they are concerned with. No more highly customized data for the UI. This is what is lending itself to DFD (Design First Development). While DFD is a logical future step, it may not be the best design tactic for enterprise applications. As Joseph Moore brings out, it doesnt work well for scale.

Still the UI is coming back into the limelight as the driving force behind applications. My latest project is moving forward because of a nifty JS/CSS/HTML only mockup. Because I started there, I know that I can simplify my server code. I don’t want to say that DFD is the way to go, but sometimes it does help to consider it.

A qote for this week:
"And a word to website designers: Most of the time, most of us aren't looking for an "experience". We're just looking to find stuff. Bear that in mind." - Doc Searls

The Ajax Problem

I wont deny not being inspired by Alex Bosworth and Jeremy Keith, but I think that Ajax has become some what of a problem. As buzzwords go it has gotten way out of hand. There are even debates about what makes an application Ajax. Some say it only needs to use the XHR methods, others say it must pass XML.

Then there are the JSON posers who stick their nose up at the mention of Ajax. Their reasoning that their webapps don't use Ajax, they pass native JSON objects, which are faster. But then when they are asked how they pass data, admit to using XHR. But, they all look down their noses at anyone who uses flat HTML, and wouldn't even scrape their shoes on a site that doesn't use CSS or JS. I read an article in Linux journal Battle of the Ajax Mail Packages. I ask myself why does Ajax have to do with mail?

There are all kinds of buzz words that have gotten attention: Push, real-time, SOAP, DHTML, XML ... and they are all a part of our vocabulary now. At one time or another they all were the basis of hundreds of purchases. I have even been moved to 'sell' a concept with the Ajax buzzword. Ajax is a leap forward in web design, and people are so busy in thinking if the can use Ajax, they don't stop to think if they should.

When do you make an application a fat client? That is a choice I have a hard time making. I can develop faster and add features sooner when it is a web based application. There is no code roll, so I save time in supporting the installer and the application. Although the difference in function to the user isn't much there is more time involved in a client deployment.

This may lead one to think that a client application deployment is more thought out. Maybe you tend to be more careful when you deploy an application this way. Really? I'm not so sure. The same poor choices are made by the same bad decision makers weather it happens fast or slow. The problem there lies in procedure and engineering. "Ajax Applications" seem to be lacking emphasis on this. In fact a application may exists simply because it is just that, what they call an "Ajax Application". I hope we look back on 2005 and 2006 to see that we made the right choices, Ajax or not. Does a good application require Ajax? Is the fat client dead? A good application does not need to stand on buzzwords.
Give me a thought out app or become vaporware!

Your Browser Broke My Webapp

Readying to embark on my first highly JavaScript driven official project, I have been looking for answers to problems I have always had. I want to make this app user proof. One of the problems of single page JS driven “Chubby/Husky/Thick”(take your pick) apps is that most of them are developed without taking the rest of the browser into consideration. I have see many postings about the 'browser causing problems with their web apps'. Huh? The forward and backward buttons are said to break 'Ajax' applications. Isn't it called a 'browser'? It is ment to allow you to navigate documents. I read suggestions to 'build your own back and forward buttons to keep the user from using the ones in the browser'... again, what? I plead with all developers, do the research. Although there is that 'error' part in 'trial-and-error' programming. Usability studies as well as real world examples prove that duplicating controls for similar but not the same functionality cause user confusion. This post and many others. suggested giving web pages the ability to disable back and forward. I shudder to think of the irritating things that would lead to. Being truly trapped on some advertisement that makes you blush. It is clear that at over 20,000,000 hits on Google there are alot of people thinking about it. I read about an interesting hack today that raises a good question, which I will rephrase.

Why fight the browser?

Do you really want to work against the environment your application was designed to run? There are better ways. Like programmatically placing entries in the history of the browser. A good library for incorperating in your tool box is Really Simple History (Tutorial here). There is also proper use of cookies. Also ASP.NET has an interesting way of handleing it in the form of the state string. When not abused, this is an interesting way of handling things. The sad fact of the matter is that more often than not, it is abused. It though, does not directly handle the problem of bookmarks, which may be another subject. Also, there is discussion of a document.save() out there on W3C for discussion. There is an eventual need for the browser to be fully aware of what JavaScript is doing. Maybe it should even save some sort of dom history. IMHO unlimited DOM undo would be my eventual choice, but we will see.

So lets step back for a minute. As programmers we know what is easy. We know what is logical from an operation standpoint. But, what we need to ask ourselves is 'What is logical to the user?' I came across this post. This is the best question you can ask yourself. What has twenty-two years of programming taught me? It doesn't matter what I think about how it should be done. The end product needs to have an interface that users will use. If users knew what programmers new and thought like them, they would just have a bunch of databases out there and a black shell window for a desktop, forever typing in INSERT and UPDATE commands and telnetting from BBS to BBS. Sound like 1989?

So, I am sure someone will have something to say about this, but people see back and forward as undo and redo. Also when you close an application that has unsaved data, it should ask you if you want to save. Granted, not every click or keystroke needs an undo history, but there should be certain actions that a user should be able to undo. But, now, if we are using the back and forward buttons alone for this function, the user may not always logically seek them out for that function.

For those users who have been conditioned to the ways of the JS application, we can offer them what they perceive as additional functionality. That is undo and redo buttons. Hold your email, I do understand this is like what I said to begin with, two sets of buttons that do the same thing. The difference here is that the buttons do not look the same. This way we are seemingly adding a hook to the back and forward events and piping them to undo and redo. The user will think themselves clever if they figure this out. Yet another bonus.

So lets put this into perspective. How would this play out in the real world. Say a user is in your shopping cart. They click on an item thumbnail to see the details on that item. Then they decide to place that item in their shopping basket, and they click 'add to cart' or drag the thumbnail to their cart. Then they decide they don't want it in the cart. What do they do but hit the back button. Your application recognizes this and asks 'Are you sure you want to remove xxx from your shopping basket?' They say yes, and then the user wants to see the list like it was before they clicked on the thumbnail, and they click back again, and the details are closed. All without reloading the whole page.

Does this not seem natural? Actually, it may not to a conditioned web user. But that brings us back to what would happen if an unknowing user did hit back? Until the browsers give us some native way of dealing with this, we have to choose.