Script/Asset abuse: this is getting ridiculous!
Frameworks like YUI, JQuery, Mootools, Dojo, etc., are arguably the best thing to have happened to JavaScript in 10 years. I remember when I first learned about their existence. I was coding my own animation script (functional, not OO, and definitely not efficient) that didn’t do anything fancy; just scrolled up and down. I remember then hearing about dojo, and thinking I’d wasted so much time.
Then what I did, was go around to all the different frameworks. I don’t even think JQuery existed in it’s current incarnation at that point (December of 2005), and I looked around at as many as I could (dojo, mootools, and a few others that have since become relics). This post though, isn’t about the greatness of these frameworks; rather it’s about the terrible abuse.
With any new technology, there will be people who embrace it for ease of use and creating a new standard, and then there will be those who completely abuse it. The screen shot below is a perfect example of that (click it for the full size):
If you can’t see what I have a problem with, then you need to leave this post right now. For everyone else, this is an absolute joke. This is for a travel promotion site called StudentCity. My count of javascript assets: 20 (excluding any dynamically load ajax/jsonp requests). My count of css assets: 11.
These tallies were retrieved via after the DOM had been rendered, so they may not match up perfectly with the source, but I assure you they’re accurate.
If you visit this site, you’re not going to notice too much. A few swfs, a bit of animation, and a few non-css related hover effects. In no way, should this account for the number of requests for just js/css assets. It doesn’t make sense, and is terrible programming/development. I understand that in many projects, control is sometimes non-existent. You need to conform to someone elses demands, some other developers tendencies, or some other designers inexperience. But for the firm who developed this site, if anyone had taken a look at the source after it had been finished, a huge red flag should have gone up.
Concatenating files is easy; minimizing requests is easy, and a faster client side render time will actually make you money, for a relatively low cost (maybe 2 hours). This speaks to what frameworks are doing these days.
JS frameworks, and even php/server side ones like CakePHP and CodeIgniter (ones I’m working with now) are leading to a generation of websites and applications that were developed by people who have very little idea what they’re doing. I don’t think it’s much different than the age of Frontpage/Dreamweaver/GoLive developed sites, but it’s certainly not something that you should be paying for it you’re working with a development firm. It’s annoying as a developer to see this, and probably a do-or-die thing if I were to be working with or hiring another developer to work with me.
“User Interface Design Heuristics”: amazing article!
One of the best article’s I’ve read in the past month is entitled Heuristics for User Interface Design
In short, it’s a set of suggestions rather than rules, that should be kept in mind when designing a user interface or experience. I’m tending to lean away from the word interface, as an interface is only good if it’s experience is effective. Gmail’s experience is what affects me, it’s interface is just what I look at rather than what I use.
What’s even more impressive about this list is it was first developed in 1994. I don’t mean to sound condescending in terms of advice coming from 15 years ago, but it’s shocking to me to find interfaces such as Google’s, Twitter’s, and Basecamp’s so incredibly in line with every single heuristic recommended.
My personal favorites:
- Visibility of system status
The system should always keep users informed about what is going on, through appropriate feedback within reasonable time. - User control and freedom
Users often choose system functions by mistake and will need a clearly marked “emergency exit” to leave the unwanted state without having to go through an extended dialogue. Support undo and redo. - Aesthetic and minimalist design
Dialogues should not contain information which is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility.