Monday, January 28, 2013

User Interfaces and Logging

The browser history takes on a new reputation in light of modern web application development. It seems that the browser history — the navigation capability of web browsers used to traverse web 1.0 — can either help, or just get in the way. The browser history might get in the way if you're striving for the complete desktop experience in your UI. This is where the back button is viewed as a hindrance, something antiquated that our code must be prepared to handle but offers no practical usability. On the other hand, the browser history is something that the web grew up with. It's as natural as HTTP or HTML in a web application. The web is supposed to be stateless. The URI a user visits inside an application shouldn't care about order. Regardless of what patterns your web application follows, the user interface needs to communicate and change state. With modern Javascript toolkits, the state of the user interface itself is becoming more and more detached from the state of the server-side resource.

Logging, as used in web applications, is centered around the resource, the thing in the database and represented by the UI. When a resource changes state, we track that event in the logs the application writes to. Maybe this is just a routine update, everything goes smoothly, and just as every other common occurrence, we can mark this as an informative note in the logs. That is, this is simply part of the audit trail, and doesn't need special adornment. But, on the other hand, something goes wrong. That is, something that should have worked, all the semantics of validating the incoming state change request were executed, but the disk is full. The permissions on the operating system were messed with and have the side-effect of the action not working. These are things we want to call out in the logs as being important. Something we expected to work, but didn't.

In the old web, where there wasn't as much to user interfaces as there are in browsers today, this type of logging alone was sufficient for almost any web application. The coupling between page and server-side resource was tight, and anything that could go wrong and was worth tracking, was logged on the server. This coupling between UI component and server-side resource is loosening. It is no longer the case that an error on the sever is to blame for 100% of what the user sees as a defect. It may in fact be the case, that the UI code is entirely to blame. So how do we find out?

Browsers have fantastic developer tools. Out of necessity. There are so many moving parts in Javascript applications now that developing without these tools would be next to impossible. So why can't we just use the console object to log what our UI is doing? You can use it, and in fact, you should use it in development. The problem comes when practice dictates that we shouldn't be treating development tools as part of the browser platform when it comes time for production. It makes sense in a way, that the application code should really focus on the core browser capabilities in rendering our application user interface. Logging capabilities introduce too much risk on external dependencies. But then again, every browser is different on so many levels that we don't gain much in the way of portability by excluding the use of the console.

From my point of view, the solution is to make user-friendly logging a feature of the application itself. By that, I don't mean that we need to start changing the way we do logging on the server, or even expose any of that to the user. Just consider the fact that if you're creating something even moderately complex and it lives exclusively on the client side, perhaps it needs a dedicated view of whats happening. Even a short-term session log that isn't persisted could prove useful. Let's give users the tools they need to help improve our code in a participatory scheme.