Party Like it’s 1997: The Curse of the Back Button

Haven’t you heard? DHTML is cool again. Now, before y’all run out scriptin’ your own little cans of Asynchronous JavaScript + XML , let’s pause for a second and consider these observations:

  1. DHTML has inherent usability issues. These issues are still present to various degrees even in all new, slickest applications. As Scott Isaacs states in his post

    The user-interface issues revolve mostly around history and refresh. (For example – In GMail, navigate around your inbox and either refresh the page or use the back button. In Spaces (IE Users), expand and view comments and hit the back button.  I am willing to wager that what happens is not what you really want).

  2. DHTML usability issues are here to stay. Unless some visionary scripting genius strikes again, they will keep DHTML as an application platform in the category of audacious hacks. Of course, the usability undoubtedly will be sacrificed on the altar of coolness: “What? You can’t click back to the album from a picture on Flickr? Well, boo-hoo! What would you rather have, a clunky extra click or the wholesome goodness of Flickr? Fuggetaboutit!”.

So, what is the nature of these issues that Scott was talking about?

DHTML vs. Usability: The Crash Course

In the typical world of Web, clicking on a link makes the browser fetch request to a Web server and deliver a new page.

At the moment of the click, the page you are on is deemed departed and added to the browser history (so that you can click the back button to return to it later, if you’d like)

DHTML provides the capability to intercept a click and, instead of fetching a new page, stay on the same page and do something with it (like open a menu or unhide a section of the page, or make a creepy clown jump out from the bottom).

At this moment, we are faced with an interesting dilemma: even though we clicked on a link, we haven’t departed the page. So, how should the fact of the click be recorded in browser’s history? Is this just a click or  some kind of weird “virtual“ click? And, if the back button is clicked, what should occur? Should DHTML script recognize this fact and adjust the state of the page accordingly? Should the creepy clown retreat back beneath the bottom of the page?

While there are are various ways to answer these questions, the fact that remains is that browsers were not originally designed to account for that kind of state change. There is no definitive way to detect the event of clicking back button. Heck, you can’t even see where we are in browser history from inside of the page!

The issue was further complicated when the XMLHttpRequest capabilities were introduced. With XMLHttpRequest, clicking on a page may result in content being loaded from the server and added to the page without leaving it.

Naturally, this opened doors for the thinking that maybe the user never needs to leave the page. Glory! Glory! We can build entire Web applications that are based on just one page, which changes its entire appearance using nifty server roundtrips behind the scene. “But… what about my back button?“, asked the ordinary user.

Web Page Paradigm

Developers, I am here to remind you of the Web Page Paradigm, put in words so eloquently by Mark Hurst:

On any given Web page, users will either…

– click something that appears to take them closer
to the fulfillment of their goal,

– or click the Back button on their Web browser.

Now, please repeat after me:

The browser back button is an essential part of user experience and every effort must be made to make it operate flawlessly within your application.

There. Whether you develop DHTML applications as part of your job or just as a hobby, it would not hurt to memorize and stick to the statement above. Feel free to print it out and frame it. Or cross-stitch it. Or put it on a t-shirt (Now, there’s an idea!)

Of course, with the back button comes its buddy, the forward button, which must also work in complete accord with your application. In other words, your application must be “clickable” back and forth transparently, as if the user was visiting the old-fashioned, pre-DHTML pages.

As an extra caveat, consider the bookmarks. In the Web browsing experience, any page can be bookmarked. So, not only your application must be “clickable“, it must also be “bookmarkable“ (I don’t think that’s a real word).

As a person who spent a lot of time working in DHTML trenches and looking on the Web, I have to admit that I know of no application or technique that universally makes any DHTML application adhere to these principles in all major browsers. In my experience, you can only go so far with what we have today. From limitations like the absense of an event model that would allow DHTML to react to history buttons to bugs that disable even a possibility of establishing the correct current location, this  is a tough one.

But I can’t know everything. Maybe — just maybe — there is a workaround or a hack hiding somewhere that brings normalcy to DHTML Usability.

Social Content Management

So, you’ve revolutionized the way people access information. Again. Just after the novelty of a search engine wore off, the ingeniously simple magic of content aggregation is taking the world by storm. Now, you don’t look for the information — the information comes to you. More than that, with the advent of casual blogging, everybody and their grandmother — quite literally — can be producers of this information. Spaces, Blogger, the oft-forgotten LiveJournal, and other online services make it almost too easy for you to start your own personal feed, ready to be subscribed to in a matter of seconds. Type away, grandma! The world is listening.

And type they did. Suddenly, everybody has a blog (“online journal” is so two years ago, you know). People are pouring out their emotions, latest tidbits of news, however big or small, linking to each other, expressing their thoughts, ideas, from asinine to wickedly brilliant. The collective chatter is getting louder and more diverse, adding more and more harmonics, fast approaching the complexity of a white noise… And when my desktop aggregator tells me every two hours that there are 500+ new posts found in 100+ feeds, I know something’s gone terribly wrong. The magic spring of information turned into the busted open hydrant of blabber. Now what?

Welcome to the field of Social Content Management. Just a couple of years ago, its older cousin Enterprise Content Management (ECM) was all the buzz. But unlike ECM, Social Content Management is not here to support and enforce business rules, workflows, and an overarching information architecture of content. You can’t enforce workflows on a blogging community. Suddenly, it’s all about what sites you link to, what others think about you, whether and in what context they link to you. Rather than business rules, it’s cliques, networks of friends, and circles of interest. In this new world, content management is a byproduct of social interaction. There is no editor. There is no producer or reviewer. Instead, editing and reviewing activity is woven into the process of blog surfing. Whether it’s commenting on a post, clicking thumbs up or down button, pinging a TrackBack, even adding a link to the post — each of these actions is used to infer more information about organization of content.

Speaking in definitions, Social Content Management is a set of concepts, methodologies, and standards, which enable and facilitate creation, organization, and maintenance of content by means of social interaction of individuals online.

To avoid being egged mercilessly, I must disclaim that I didn’t come up with this term first, and certainly didn’t invent the notion. Slashdot is a shining example of Social Content Management, and this site has been around for a while. All I am trying to do is organize and orient the various thoughts regarding this subject to gain a better perspective on the field.

Of course, just naming the process does not solve the problem. By definition, Social Content Management produces highly compartmentalized and biased content structures. Not having centralized due process makes objective organization impossible, which makes it hard to get out of the boundaries of compartmentalization. However, centralization or accumulation of content organization leads to various issues of ranging from API or even problem domain disparity to identity verification and privacy. In other words, the field is wide-open. Actually, it’s more like a steppe, with rolling tumbleweeds and wild grass hiding treacherous ravines.

All the more exciting, isn’t it?

Feelin’ all AJAXy: How Prince of Salamis Became the Moniker for Stuff Done Before

Developers of the MSDN Library site, I feel your pain. You’ve perfected technology years ago (and I am not talking dog or Internet years!), quietly enjoying its success, only to have all of its coolness taken away by Google. Then, some hotshot comes along, slaps a four-letter moniker on it and bam! — you are so out of the picture, it’s not even funny.

For those who haven’t been paying attention (Watchful Mary Jo and even the Noble Scoble included, methinks), Microsoft had used AJAX in production sites for many, many years. How many? Well, let’s just say that there wasn’t an XmlHttpRequest spec properly implemented in Mozilla. And certainly before the term AJAX was coined. Observe Exhibit A, the tree menu of the MSDN library site: asynchronously loaded using JavaScript and XML, beta in 2001, live in early 2002.

What can you do, Microsoft dudes? You just don’t know how to coin cool four-letter acronyms. Although I have a feeling you could think of a few four-letter words right now…

Progressive Enhancement: Couldn’t have said it better myself

Jeremy Keith has a very nice and complete summary of pitfalls of using augmented client-server interaction on a page (the term Ajax seems to be catching on).

In short, just because you’ve mastered XmlHttpRequest or IFRAME tricks doesn’t mean that your page had suddenly overcome all traditional limitations of a Web page browsing paradigm and now you are free to do whatever you feel like. All this Ajax stuff do is offer you a capability to enhance the user experience, but applying it to actually achieve better user experience is a far more difficult task.

In fact, this task is now actually more complex than it was prior to Ajax existence. Now you have to carefully balance between the old-fashioned page paradigm and new functionality and make sure that neither steps on each other’s feet.

Here are two more examples of poor progressive enhancement:

  • GMail. Don’t take me wrong, I love my GMail, but have you looked at the source code of this thing lately? Don’t — it will blind you. It’s not even valid HTML. GMail now offers “less-fancy“ version for “less-supported’ browsers. Well, there’s a novel idea — you might have not needed to create a separate version of your service if you started your coding with progressve enhancement model in mind.
  • MSN Spaces. It seems that while the rest of Microsoft is slowly catching up with structural markup movement and starting to understand importance of valid and accessible HTML code, the Spaces seem to be stuck in the 1999’s “World’o’Tables“. I won’t go into details (but I can, if you ask me :), but their user experience could have been dramatically better if they used progressive enhancement and structural markup.

Complete Credentials Screening

Here’s the latest iteration of the Credentials Screening module (for more information see this and this posts). It further improves the way credentials screening operates, introducing things like Windows authentication cookie reminder (because sometimes Explorer “forgets” that it had already authenticated with the site and issues a new challenge), better browser detection (since no other browser supports silent authentication, only MSIE will invoke the credentials screening process), corrected support of Forms authentication, and last, but not least — Authenticate event, which your application can subscribe to by simply implementing a CredentialsScreening_Authenticate method in the Global.asax.cs class. The signature of your method should look like this:

protected void CredentialsScreening_Authenticate(Object sender, EventArgs e) { /* body of your method */ }

This method will be called any time the Credentials Screening module successfully authenticated a user. Neat, huh? Oh, by the way, almost forgot:

If you want to explicitly make the login dialog pop-up (for example, you have a “Login” button for those who couldn’t authenticate through screening), use this static method to retrieve it:

public static string ScreeningModule.GetManualLoginUrl(HttpRequest request);

Well, this about sums it up. Let me know if you find any more bugs or opportunities for improvement.

Of Men with the Brain on Both Sides and a Utopian Cult

Has it really been that long since my last post?

Nikhil Kothari updated his already cool site and I just had to leave a comment to compliment him on the great design work that he’s done. It is rare that a function person (i.e. software developer) has such a good handle on the form (visual presentation). In my experience, most people have either function side or form side developed. You are either a brilliant software developer who can only draw stick figures or a design genius whose eyes glaze over as soon as you hear the word “polymorphism“.

Unfortunately, the modern software development process outright requires you to possess both in order to be successful. Software design is half user experience. And the rising expectations of a quality user experience is what makes form suddenly so important. The users no longer find stark green-on-black TTY terminals acceptable — the PCs had spoiled them to point and click. They no longer want to fill out ten-page-length forms and type in dates — the expedias and amazons had made them expect to click once to get the reward. They seem to gravitate, sometimes subconsciously, toward professionally designed interfaces. The user wants to feel comfortable, and the bar of “comfortable“ slides up continuously.

Those who bridge the gap between form and function can keep up with this slide easier, simplifying the complexity of a development process by keeping both parties in the same brain. These types are the real gems that companies need to hunt for — if they want to stay in software development business. Soon enough, if you don’t have one of them, you won’t be able to keep up.

One other thing that I had in my comment is an offer to convert Nikhil to the “structural markup” religion. I neglected to mention that it’s actually more of a cult, where we share unyielding, radical beliefs about how HTML markup should be done, shave our heads and sing creepily monotonous chants. Well, we’re not yet doing the last two — the logistics of choosing the right chants are insurmountable, given our fondness for standards and the reputation for quickness that W3C has.

However, the “structural markup“ people do have strong beliefs about the markup. In its most abbreviated form, the idea of structural markup has to do with making sure that the HTML code reflects the structure of content, not its presentation. The presentation must rest entirely on the shoulders of CSS and client-side scripting. The markup is only there to reflect the logical structure of content.

For instance, my article about Piped Lists is an example of how you should only think of a horizontal list of links, separated by pipe characters in terms of its structure — it’s a list of links, which is expressed using UL, LI, and A elements. The parts about “horizontal” and “separated by pipe characters” is immaterial to the content structure and must be expressed using presentational means — CSS in this case. Similarly, the TABLE element should only be used to express two-dimensional relationships in content, not how the content is laid out. I am sure you’ve heard of “table-less” layouts before.

What are the benefits of structural markup? Well, quick googling reveals lots of existing articles attempting to list them. In my mind, it all comes down to separation of content from presentation. With structural markup, we have an opportunity to make a clean separation between the structure of a Web page and its look and feel, which is a requirement for any modern Web application, driven by the need for better maintainability of code, accessibility, and even performance.

Making your way into the structural markup world is not easy — the road, while marked, is quite bumpy. The uneven support of CSS and disparities in DHTML DOM implementation across browsers make for some hair-raising rides, frustrating enough to turn away even the stubbornest of the followers. Even so, the promise of the future where Web content is just content and nothing more is good enough for me to keep going.

Better Credentials Screening

In my first post about credentials screening, I’ve offered sample code, which implements the solution. Being the quickly thrown together piece of code that it was, the sample had a couple of quirks. Oh, nothing big — just things like being stuck in an endless loop when you access it with a browser that has cookies disabled. So, here’s the new, improved rendition:

  • Provides more graceful handling of various browsers. The actual screening will only work on IE, but at least other browsers will not get stuck in a loop.
  • Handles browsers with no scripting enabled — while this is not a perfect solution, at least the script-less users will see a message asking them to click through to the actual page.
  • Silently supports forms authentication. If forms authentications is enabled, successful screening will result in user authentication. Otherwise, the system will revert to the login screen.
  • Thanks to the tip, provided by Craig Andera, the module no longer requires a special RequiresAuthentication.xml file. This is almost completely a drag-n-drop solution now — you still have to register it in Web.config.

Take a look — let me know how it works for you. I welcome any suggestions, especially on how to improve no-scripting support.

NOTE: The code in this post is deprecated by the code in this one. The link to the old code is for historical purposes only.