Three User Experience Lessons from the Terrible Garbage Web App Hall of Shame: MyParkingWorld.com

The web is incredibly empowering. Perhaps that's why when something is so thoroughly broken, I feel it viscerally in my stomach. Nausea and gnashing of teeth ensue.

That's what happened today when I opened up my browser to look for monthly parking in San Francisco and found IMPark's monthly parking search online. At first glance, everything seems fine.


But peer deeper into this web app and you'll find the soul of a twisted, infuriating, horribly broken waste of electrons.


Lesson 1: Reset state in Javascript on DOM load

Just because you set your form elements to be something in your outgoing HTML doesn't mean that you'll be in the correct state. They're doing an elementary AJAX call (why the hell is this in ajax anyway?) to refresh the cities. But what if I select USA, then refresh? This JS totally assumes that it will always be in the correct state -- but my browser stores form values after reload so as to avoid data loss. Incidentally, this is what happens also if you use the BACK button. And contrary to popular belief, the back button is great. Users love it. I love it.

What ensues isn't pretty...


OK, rookie mistake. But what happens when I select something, anything? I should be able to click to Canada, then back to USA, right?



Nope. Amateur hour. Then click around a bit more and you get...

WHAT THE...  How did we get here? Wow, total error fail. I hate you.


Lesson 2: Let me navigate the way I want to navigate


OK so I've searched for San Francisco. Here it is.


But for some reason, I can't cmd-click to open each of these lots in a new tab. This is a habit I've picked up to avoid the general latency of the web -- why round trip and go back/forth when you can just open a ton of tabs and triage as you see fit there?

Actually, this is a form element, of type submit. Are we in like 1995 again? What the hell is the point of

This is bad also for SEO. OK, amateur hour web dev, what are you thinking? You're costing IMPark money by hiding this info from Google. Way to go. If I search for "Mission Bay Parking" I should get to the page you're hiding behind a form input submit. TWO THUMBS DOWN.

Use a link. A HREF! Don't navigate using Javascript. Don't navigate using a POST from a form input submit. I'm starting to understand why people are so obsessed with REST-- because if you're RESTful, you won't do retarded things like this. Now I understand that the RESTful formalism is like a straightjacket that keeps an insane person from cutting themselves.


Lesson 3: Test your damn app people. Please.

OK, so I'm looking for lots cheaper than $250/month in my area. Yes, that's a parking space, not rent. That's the extortionary fee charged by my current apartment building in South of Market.

Oh, I guess there are none. Oh wait. That's not right.



FAIL!!! In fact pretty much all of the listings have rates that are less than $250/month. First, that confirms SoMA Mission Bay is basically the most god-awful overpriced yuppie-trap in all of San Francisco. Second, that confirms that the creator of myparkingworld.com is too busy smoking crack to test if their app works AT ALL.


In conclusion

IRONY OF IRONIES: The creators of this godforsaken mess were nominated for the MSDN Code Awards. Microsoft, HOW COULD YOU!?

I feel the KnowledgeTech development team should win the award because the Monthly Parking System project is a true testament to Microsoft technologies and tools and their high-level of integration and cohesiveness.

For Microsoft's sake... I hope not.

Filed under  //  bad UI   javascript   user experience  
Comments (7)
Posted

Bleeding edge Javascript techniques from the creators of jQuery, Prototype, Dojo and YUI (liveblogged from #sxsw)

Cross posted from my personal posterous, where I posted a little bit while we were at SXSW...

Here are my quick notes from SXSW talk "More Secrets of Javascript LIbraries"

Bundling/dynamic loading
(Nate Koechley, YUI)
Javascript files for modern websites really have gotten huge. So it makes a difference how you load them. Some cool tools mentioned:


Meta language libraries
(Andrew Dupont, Prototype)

  • GWT turns Java into Javascript
  • Pyjamas turns Python in to Javascript
  • Cappuccino by 280 North turns Objective-J into Javascript
  • Google Caja turns Javascript into safer Javascript.

Google Caja sounds like a fascinating way to allow rich JS embeds on-page, perhaps solving the XSS dangers of embedding 3rd party JS. Definitely going to check that out later.

Dupont points to Resig's blog post about JavaScript Language Abstractions that a lot of these meta-language libs actually divorce you from being able to harness the full power of Javascript because you never actually learn how to write it.

"Thicker abstractions have more hassle, but offer greater rewards." --Andrew Dupont

At the end of the day, I think you use the tools that work best for you. I love what the guys are doing at 280 North, but a site like Posterous probably wouldn't use it because we're more of a native web experience. And in talking to them, they're not meant as a replacement for Prototype, etc. Cappuccino is really for extra-rich internet apps where you might use Flash/Air, instead of classic native websites. So different strokes for different folks!


Accessibility
(Becky Gibson, IBM / Dojo)

ARIA = Accessible Rich Internet Applications. New standard for supporting screen readers, magnfiiers, etc. Lets us JS developers create tree controls, tabs, and rich JS functionality but still have it work great for those needing assistive tech.

Biggest issues with accessibilty and rich JS content:

  • Adding dynamic controls that you create to the tab order -- by default only links and form controls are added, so if you add onClick listeners to direct divs, etc -- screen readers often can't even see these things.
  • AJAX'ed content that gets inserted into the div sometimes doesn't get picked up because assistive technologies don't get notifications of page updates.

Pretty cool stuff coming -- hopefully browser support comes sooner rather than later, since that determines when we'll be viably able to use these new standards. Might have to switch to jQuery to take advantage of this on Posterous.


Performance and Testing
(John Resig, jQuery)

Cool jQuery profiler plugin for Firefox tells you what's happening during load time.

"The very act of measuring it is causing the problems." --Resig. Timer resolution is only 15ms on Windows, for instance -- error rate 50 to 750% using your own JS timers.

Also cool: Firefox, Safari 4 and IE8 all have built-in JS profilers too.

Testing using FireUnit. You can actually add profiling data as part of tests, so if certain tasks take too slow in a given browser you can build that into your JS test suites. Cool.

John Resig is a badass. He just busted out Big-O notation on analyzing JS DOM manipulation.

The jQuery team runs 6 test suites in 11 different browsers (not even including multiple platforms) that must be run on every commit. But luckily they created TestSwarm so you can automate browser JS unit tests. Also awesome -- can script manual testing cross-browser too. Brand new project John Resig is working on now, but he says you can sign up on the site to hear about when it's up.

Filed under  //  accessibility   dojo   javascript   jQuery   prototype   YUI  
Comments (0)
Posted

I am really digging WMD, the simple JS Markdown Editor used on stackoverflow.com

This is the way markdown was meant to be used. Definitely putting this on the list of things to add for posterous... It can't possibly be the default editor since WYSIWYG is what everyone expects at the end of the day, but for power users this is really going to move the needle on really dead simple markup.

Filed under  //  javascript  
Comments (2)
Posted

Cross-Domain Communication with IFrames

This article explains iframe-to-iframe communication, when the iframes come from different domains.

Great article, and details a really cool hack to get cross-domain frames to work. It's one dark recess of web technology that is actually quite useful, but is rarely explained in such proper and interesting detail.

Filed under  //  javascript  
Comments (2)
Posted

How to get Internet Explorer javascript debugging really set up using Visual Web Developer 2008 Express (free version)


I don't know why all the existing articles out there in Internet Explorer javascript debugging always tell you to try the Microsoft Script Editor or other such steaming piles of feces from 2002. Microsoft's Visual Web Developer 2008 at least was released in the last year of the Bush presidency, instead of the beginning of the first term. They GET you by disabling the ability to attach to existing processes, but turns out you don't need to attach... you can just create an attached browser directly out of the free version.

Epic win.

First, download
the free version of Visual Web Developer 2008 here. Install it. Enjoy waiting twenty minutes. Get a cup of coffee. Don't sit there waiting for the worst out of box experience ever, whatever you do.

Next, go to Internet Explorer's Internet Options and set Internet Explorer as your default browser. I know, terrible, but you gotta do it -- otherwise VWD2008 tries to use Firefox, Chrome or your other superior default browser and you lose the ability to debug IE7 in all of its awful putrescence.

While you're in Internet Options, you should also de-select disabling script debugging and enable debug messages in the Advanced tab.

Now you have to create an Empty Web Project by clicking New > New Website. Now click Debug > Start Debugging. It'll open a new IE window pointed at localhost, but just fire up whatever to-be-debugged website in that window. 

Awesome. Now any errors should drop you into the VWD2008 debugger. ROCK ON.

Filed under  //  debugging   Internet Explorer   javascript  
Comments (0)
Posted

Javascript super killer tip: Always use innerHTML if you have no JS lib and it has to work in IE.

Recently while writing some features for Posterous, I ran into a super simple but insanely annoying bug where IE fails to properly pick up id and name fields when creating new DOM elements in JavaScript using document.createElement().

Internet Explorer completely fails to add created DOM elements to the lookup table of named elements as targets. If you generate an iframe and want to POST to it from your programmatically generated FORM tag (by setting TARGET="your_new_element_name"), you're out of luck and IE will try to create a new window instead.

InnerHTML to the rescue. The abomination of standards that is innerHTML works pretty well across all browsers. John Resig is so right when he says the DOM is a mess. Thank god for things like jquery.

Filed under  //  DOM   Internet Explorer   javascript  
Comments (3)
Posted