Cutter's Crossing - Usability

The Joys of Developing for Internet Explorer

Thu, 09 Feb 2012 10:51:00 -0400

Note: Follow the madness here to it's conclusion, to discover yet another "Really? I didn't know that..." IE moment, that may save you heartache and pain. Is the sarcasm evident in my title? It should be. While Internet Explorer may have been "groundbreaking" when it was released, it has ever been the bain of the web developer's existance. Why, you ask? Because it refuses to adhere to standards, and just operates differently than everyone else. To be fair, Internet Explorer 10 is in the works, and supposedly closes the gap a fair amount (and even wins out in some of the html 5/css 3 support), and 7, 8 and 9 did progressively improve (if slowly). Unfortunately the fact remains that some companies/organizations/governments are stuck on Internet Explorer 6, or maybe even 7. If you are a web developer, and write cross-browser web applications, chances are Internet Explorer has hit you more than once in your career. It's the dumbest things that hit you too. The most obscure "WTF!?!" moments that drive you crazy. That is a daily experience for me now.I've been a server-side developer for over two decades now, but in the last several years I have dealt more and more with client-side development. Why? Well, I started with HTML, and got into Javascript when it was introduced, and then got into server-side programming, so I already had some roots. With all of the work that I've done, working with Ext JS and JQueryUI, my current position threw me to the wolves to work on standardizing our application's interface development. Fun, right? It is (a lot), but the client is one of those mixed environments that is entrenched in IE, typically at 7 or 8. They can't upgrade, so it's our responsibility to make sure that our interfaces can render and function properly in these older, buggy, non-compliant POS browsers. (Note the frustration here.) Let me layout one of those typical, what-the-hell-is-goin-on-here, Internet Explorer moments for you.

The Application

Like most good development companies, we've made the shift to more modular, reusable code. It's a legacy codebase, serving the client well for years, and goes through constant review, revision, update and improvement. Many of us (developers in general) would love to just scrap our current codebase and start from scratch, but that's not really practical in most situations. What happens is you begin to slowly move away from The Big Ball of Mud design pattern, by replacing small pieces of your application as updates/changes are required, with more modern code. Rather than one huge application, what you end up with are small, mini-applications, that can be plugged in anywhere within an application. Each of these 'applications' then have their own supporting files: html, javascript, and css. Welcome to the fun.

Collision Control

At this point, the issue isn't necessarily browser specific, but rather logistics. When you start adding in multiple mini-applications, things can (and will) butt heads. You will have issues with race conditions, as multiple scripts use variables of the same names, have functions with the same name that override each other due to execution order, id's repeated in a page (IE hates this a lot), and multiple event handlers accidentally added to the same DOM controls because selectors aren't specific enough. You tighten up your DOM selectors, come up with some variable and DOM naming standards, and learn about namespacing. Each a slow, progressive step towards sanity. Then there's the issue of accidentally loading the same files multiple times. Our application uses JQueryUI, cfUniform, TinyMCE, and jqGrid extensively. Each of these mini-apps loads it's own support files. Suddenly, you're faced with coming up with systems of control, to ensure that you aren't loading scripts and CSS multiple times.

Back to the Browser

There's a ton of debate out there about loading multiple scripts and css files. Loading multiple files has performance issues for initial download, but maintenance is far easier with these bit modularized like your display and model. In many applications things aren't complex enough for multiple files to truly be an issue. But, when you are writing a complex application, like scheduling software, customer resource management, content management, etc., the number of 'modules' you might include in a page can grow and grow and grow, especially if your interface makes heavy use of ajax. This is where Internet Explorer can actually force your hand into creating a better experience, unintentionally and generally when it's inconvenient. What happens when you load up your app, and notice that your forms (cfUniform) don't appear to be styled, and your highly configured and customized WYSIWYG editor (TinyMCE) appears to be half loaded? But, only in IE? Well, you start troubleshooting. Maybe cfUniform didn't load? No, the stylesheet is what's important here, and Developer Tools say it's there. The editor? Did it initialize? Well, the style and font dropdown info is there, even if they aren't in dropdowns. What's going on? You start removing script files, one at a time, to make sure there isn't a conflict. But wait, it works in everything but IE? Well, you try it anyway. You step debug things, trying to see a break. And you Google (and Google, and Google). These are my days. And, after three days of this single issue, you finally stumble on an obscure post (page 15 of a Google search). Please, tell me you're kidding me... Yes, Internet Explorer (at least 6 through 9) only apply up to 31 stylesheets and/or style blocks. So, when your page (1 specific stylesheet) uses JQueryUI (1 plugin stylesheet), and a menu (3 plugin stylesheets), and a nav widget (1 plugin stylesheet), plus cfUniform (3 plugin + 2 override stylesheets), and jqGrid (1 plugin stylesheet), and TinyMCE (multiple dynamically loaded stylesheets, depending on plugin configuration), and... You get the picture. Oh, and did I mention that some of those stylesheets were 10 line, IE only stylesheets to hack IE's different handling of CSS? Yeah, salt in the wound. To test this, I went looking for something that might be loaded by default, but wasn't needed on this page of my app (or at least, not for what I was testing). I found a few stylesheets I could disable in local development, and reloaded my page. Imagine my surprise when everything rendered as it should. I had to toggle it back and forth a few times just to verify. I think I spewed profanity for several minutes.

What To Do?

OK, so we had already been looking to form a strategy for combining files and minification. Notice I said "looking to". That is to say, we wanted one, and knew we needed one, and even done a little research, but we hadn't solidified one. If we had, we'd already have been working on it. Now, under the gun, with deadlines looming, we have to put it in gear. What to do? Well, in this case, improvise. Time not being on our side, we have to do this manually. Identify multiple CSS files that are used either constantly (every single page load) or extensively (85%+ page view). Combine and compress, and remove single link references from the code. Now, I didn't do this completely manually. I did write a script where I could define which files, in what order, and have the script build the file, while correcting internal url references so that image paths wouldn't break. Then I used an online compressor to minify the file. After all of this work (took the good part of an afternoon), I reload my pages and all of them function as intended, in all browsers. And, compressing 10 files down to 1, I now get my form styling, and my editor displays correctly, etc. OK, is this the ideal solution? No, we'll still develop a comprehensive (and automated) strategy. But, this gets us over the deadline hump, and proves that the multiple stylesheets were the issue, and that this type of action can correct the issue. Proof of concept. You have to start somewhere I guess. But, how much easier web development would be if we didn't have to support Microsoft's mistakes.

Anatomy of a Shopping Cart: A Usability Study

Fri, 06 Jan 2012 16:27:00 -0400

This little writeup is a usability study of cart layout and process in general. So many apps today are still sporting the 1999 click-and-reload interface, and times have changed. Users are tired of the old way, embracing the new, and if you're behind the times you could be losing clients fast. Shopping Carts are funny, terrible things. The less intuitive they are, the higher the abandon rate, and yet you have to pack a ton of stuff in there. The trick is to anticipate user workflow, and match that as much as possible, without making the user work for it too much. This is the whole precept behind Don't Make Me Think. First things first, create a method for detecting JavaScript prior to a user ever coming to the shopping cart, as it redefines the experience for the user entirely. If JavaScript isn't present, then it's either a bot, some non-Class A mobile device, or less than 1% of the desktop user. Surfing the web without JavaScript is even less of a chance than a user surfing without the Flash player. There's just too much of a user experience that is lost without it, and most standard users don't have a clue how to disable it to begin with. You end up with two separate cart processes, one with JavaScript, and one without. "Two processes?" Well, you write a process with graceful degradation, that can do what needs to be done in either scenario, and with code reusability in mind. This writeup will go over the user with JavaScript enabled. I've mocked up a simple, yet effective, cart design. This is just a wireframe model, but there's nothing here that can't be done with HTML and CSS. A user without JavaScript would have to step through the stages of placing an order, screen by screen. A user with JavaScript has to step through as well, but through JavaScript and Ajax, this user does most of their work right from the cart. Below is the mockup, with an explanation of the different stages of process to follow:

This is pretty loose. Balsamiq only allows you to do so much, so color and highlights and icons give things a lot more pizazz, but this should give you a good idea. If you're unfamiliar with Balsamiq, it's a great tool for doing simple "pen on napkin" wireframe layouts during interface design. It's also a great way to draft quick mockups for clients without spending hours of unpaid time, and even more hours on revisions. From the top down: The only button at the top is the "Keep Shopping" button. A user has to verify all the details prior to checking out, so the "Checkout" button is at the bottom of the form. The "Clear" button is also at the bottom, giving the user a second chance not to clear out. A second "Keep Shopping" button is at the bottom of the page, to encourage the user to buy more. Next up is the cart contents. A user, coming to the cart, wants to know what's in it first. This is the user's main focus, so registering for the site or entering credit details and stuff always comes after the cart itself.

There are a few different ways to handle actions on cart items. Here I show the 'Remove' checkbox. If a user hits the box, take the item out. Don't prompt 'Are you sure?' This annoys users. Of course they're sure, or they wouldn't have checked the box. Another way of handling 'Remove' is part of an action link list. There are already two other action links showing (Gift Wrap and Add to Registry), it would be easy to adjust the layout to use all action links instead (Remove at the top, Add to Wishlist, Add to Registry, with Gift Wrap last). Here's a tip though: Any of these actions will ultimately remove the item from the cart. Being tabular in nature, it's best to use a table here. Unwritten rules of cart usability: the 'Item' is listed first, unless something small, like a checkbox, radio button, or icon precedes it. The cost (Qty * Price) is always last. This allows us to build a columnar layout of the money details. If you have line item discounts, you may show the math here too, to emphasize what the client is getting. In this mockup, it's all shown below. Next, show the user some love. Discounts, Promos, Gift Cards and Coupons should follow the cart. 1) it makes it easier to calculate the Subtotal and 2) it gives the user a warm fuzzy to watch their Total decrease. If there were discounts on items, pull them out here (if you didn't do it above). Don't make a user refresh the page to get a new Total. Gift Cards and Coupons? Use Ajax to verify their validity and value, and apply it to the tally block right then.

If addresses aren't pre-populated, then the user hasn't logged in or registered or set up addresses yet. Our action depends on which scenario is the case. If the user hasn't logged in or registered, then we show them a login box, with a register button. If they login, we go ahead with the rest of the order process. If they must register, handle that registration in a modal popup and then update your area. If the system allows for anonymous users (those who don't want, or have, to register with the site), or a registered user hasn't setup addresses yet, then we display "add address" links to the display that can load modal forms to collect the necessary details.

You can't tally Tax unless you know you need to collect it. If you don't have an address yet, don't show the Tax line item. If you get an address, and tax does need to be applied, add it in right away, and highlight it, and the Total change, so there's no surprises.

And, once you have an address, then you already know the zip/postal code the order is going to. Once a Shipping Method is selected we can lookup the shipping cost via Ajax. And, if the purchase is a download, then there's no reason to show them the Shipping line item at all. Avoid the "Estimated Shipping" thing, just give them the info once you have it. If need be, show them text ("We need your address and Shipping Method to show Shipping Cost") to help push them through the order process.

Last is the Payment Method. When a user selects the Payment Method, then the input fields for this area should change to the appropriate fields for that method. Don't show them fields for every possible option, just those for the option they've chosen.

That's it. By streamlining your Cart and Checkout process to match user workflow, you should see a lower abandon rate and higher sales. There's a lot of code involved, and both client-side and server-side data validation is a must, for security purposes, but the end gain makes the effort more than worthwhile. What are your suggestions for improving Cart usability? Give me your feedback below.