I try to use this site for positive tips, tricks & posts about web development. No, really. I do. But every now and then I come across a site so horrible, so incomprehensibly broken, that I just need to call them out by name: Dish Network.

Dish Network’s website is an unmitigated disaster of usability and UI. Clearly born out of some corporate design committee, this customer goodwill-burning, will-to-live-sapping site employs some of the worst design and UI practices out there. In the end, they violate the number one rule in business: Never make it hard for a customer to give you money. But along the way, they put up every conceivable obstacle to achieving even the most simple task possible.

For starters, they use Flash-based logins. I personally believe that Flash-based logins are evil and pointless. They block accessibility and prevent use of password managers like 1Password. But in this case, it’s especially bad because there is no fall-back if you don’t have Flash installed. No Flash? You’re screwed. iPhone/iPad users? Fuck you. Users who have plug-ins disabled? Bitez moi. ClickToFlash users? Sit on it.

Next up: Mac users, you must not exist. Inexplicably, the site is very broken in all three major browsers on the Mac. Images fail to load. Accessibility support is inconsistent or outright broken. Every Flash-based button is broken because the sans font is different on the Mac and nobody at Dish bothered to check. I’m sure it works in IE6, though.

But here’s the ultimate kicker: You cannot do anything on this piece of shit site with regard to your bill. After logging in, all your account options are locked out (you know this because the broken button labels are a slightly darker shade of gray than they normally are). So all roads lead to the account profile page. After some trial and error, you have to figure out on your own that you must scroll to the bottom and re-enter all your login credentials (keeping in mind that you’re *already* logged in). First they kick you in the left nut by making it look like you’re resetting your account with an entirely new password. Then they finish the job with a Flash-based form that uses a different password validator than the main Flash-based form. Even if you wanted to enter a new password, you can’t reset your account because the form won’t validate your existing password. This effectively locks you out of the account and prevents further changes, online bill pay, auto-payment setup or any other means of managing your account. So if you happened to, say, use an exclamation mark in your password, you’re done. Game over. Pack it up. Go home. Or should I say, “Go home!”

The site has been this way for the two+ years I’ve been a customer. It’s a good thing I enjoy their HD programming or I would have kicked them to the long ago. I won’t pretend that someone at Dish will read this post and suddenly make the necessary changes, but it sure does feel good to rant.

I was kindly informed by Microtek that I’m screwed. My s400 flatbed scanner that is barely more than a year old has been bricked since my October upgrade to Leopard. I’ve been patient for months now, and finally wrote them a kind letter. I got this in response:

Dear Mr. Stringer,Please be advised that the ScanMaker s400 scanner is not supported on Mac OS 10.5 Leopard. We regret to inform you that Microtek will not be releasing software drivers for the ScanMaker s400 scanner to support this new operating system. We apologize for the inconvenience this may cause you.

<rant>

Microtek just made my infamous Dead-to-Me list with Sony, the Microsoft Operating System, and the Republican Party. Congratulations guys. I’ve got your prize right >here<.

Look for an mint s400 on eBay soon.

</rant>

Update:
The item is up for sale on ebay. Check it out here.

A very good (and brief) blog post over at Signal vs. Noise [link]. Some choice quotes:

“Programmers often have difficulty going back to older code bases because they don‚Äôt reflect the latest, greatest idioms.”

“Even if you take that project from three years ago and scrub it clean as can be today, it‚Äôs still going to drift from the best practices of two years from now.”

“Here‚Äôs something I don‚Äôt say often: Suck It Up. If you work on more than a few projects, they can‚Äôt all smell like today‚Äôs fresh linens.”

I definitely recommend reading the whole post.

Unobtrusive Javascript (UJS) is defined in Wikipedia is the practice of abstracting Javascript code to separate function from presentation. To grossly simplify things, it means completely replacing all in-line and page-embedded JS with header or externalized code that uses the DOM to access elements by reference.

To use a grossly simplified example, let’s say you have a button that pops up a window on the onclick event. Traditionally, this would be accomplished in-line as follows:

<input name=”myButton” type=”button” onclick=”window.open(‘somepage.htm’, ‘someWindow’,’ width=200, height=300′)” value=”Hola Mundo” />

To make this conform to UJS, one might put the following in an external file:

This would allow you to strip the inline code from the button, leaving only the following:

<input name=”myButton” id=”myButton” type=”button” value=”Hola Mundo” />

Again, this is an overly-simplified example, but it illustrates the concept. In real practice, UJS has some very practical use. In a world where AJAX apps and JS frameworks are more and more prevalent, teams are larger, and sites live on for years, adhering to professional coding standards becomes increasingly important. The days of copying crappy JS snippets off the web somewhere and cramming them into your web page are over (thank goodness).

That said, use of UJS isn’t without controversy. Specifically, it’s consideration as a ‚Äúbest practice” is not agreed upon by many. While the benefits of abstracting JS code make sense in certain cases, some argue that the overhead associated with UJS makes ongoing maintenance more difficult, and the time to implement the initial code take longer.

In this article, I’m trying a little experiment. Rather than sit here and pontificate on what I think, I thought I would invite some ‚Äúguest speakers” to weigh in and provide varying points of view. My goal is to let you, the reader, decide if UJS is a practice you should adopt.

For the purposes of this exercise, I’ll be taking the side ‚Äúagainst” UJS (though my actual opinion on its use is somewhere in between) and Scott Fegette, the Technical Product Manager for Dreamweaver at Adobe, will be taking the side ‚Äúfor” its use. Along the way, distinguished members of the Development Community will weigh in.

First, it is my pleasure to introduce Scott. As mentioned above, Scott has a thing or two to say about the technical direction of Dreamweaver. Before joining the Dreamweaver team, he was both a Flash Video evangelist and an engineering manager on the Macromedia web team responsible for building the site infrastructure, services and architecture that delivers Adobe.com to this day.

Before joining Macromedia in 2000, Scott spent 6 years building his skills at web design and development from it’s very inception as the director of online services at former Santa Barbara-based software developer MetaCreations- contributing both global site design and server-side framework code, and managing a team of 8 designers and developers to support the site.

Aside from speaking around the globe on web development, web standards, video production and online communities, Scott’s also a professional musician and independent photographer / videographer in his off-hours.

I needed to be convinced of the benefits of unobtrusive JS, and it took me quite a while to come around to the light, so to speak.

From an abstract level, the separation of content/data (HTML/XHTML), design (CSS) and behavior (Javascript) has long been the foundation of the MVC (model, view, controller) model for engineering. This is admittedly more important for team development/design than an individual who wears all the hats, but essentially why HTML selectors (IDs, classes) were created- to target page elements with both design and behavior, and abstract the design/behavior layers into discreet resources that could be worked on independently of the content itself.

Look at it this way- we already have embraced the fact that CSS is best leveraged externally (well, aside from fringe cases like inline styles for HTML emails and for one-off cases where a dynamic system ‚Äì PHP, CF, JSP, ASP, etc ‚Äì needs to inject a ‘temporal’ change into an HTML page or resources), as it allows you to work on one asset ‚Äì a single CSS file or combination of them ‚Äì and then see those changes propagated out to all of the content that subscribe to them. Well-formed markup can be completely face-lifted via CSS without touching much if any of the content structure. That’s a HUGE productivity boost. Sure, you can do sitewide greps to yank out blocks of code or swap it and achieve the same results, but having done that for years with large sites (i.e. macromedia.com and adobe.com, as well as the sites I worked on beforehand) it’s also incredibly fraught with issues, caveats and potential snafus. Mess something up that way, and you’ve compounded the problem to the nth degree, in fact.

As HTML-based experiences become more dynamic, and Javascript finally reaches the mature potential that DHTML hinted at years ago, it will ‚Äì at least in my opinion ‚Äì become as critical to separate the JS layer from our HTML content layer as it was to do so with CSS years ago. After all, that’s what the promise of HTML selectors were from the get-go! We’ve heard from a ton of Dreamweaver users over the last cycle that as they begin designing experiences that are more dynamic in nature, or take part in larger Ajaxian workflows with true development teams, that the inline event handler model in JS we’ve become accustomed to falls flat quickly and does not allow the tasks to be adequately separated.

That’s why I do feel it’s a very strong best practice, as well as the intention of the standards to begin with, to at least try to externalize Javascript whenever and wherever possible- particularly in areas of markup that are global for your site. Sure, inline styles and event handlers/JS can still be used ‚Äì and are no less valid – but if you can simplify and centralize your Javascript code the way we already do as second nature with CSS, it seems to benefit everyone, at least to me. Problem is, we’re more familiar with the design woes of inline CSS than the behavioral woes of inline JS, so the benefits aren’t as immediately apparent- not to mention the fact that no web authoring tool ‚Äì including our own ‚Äì handles this workflow adequately today.

Next, we have a viewpoint from Dave McFarland. Dave is the Dreamweaver editor of MX Developer’s Journal and author of Dreamweaver MX: The Missing Manual. Find out about his latest projects at www.sawmac.com. Dave has been designing web sites since 1995. He’s a professional web designer and educator who has worked with the University of California at Berkeley, Intuit, and Macworld magazine among others. He is a frequent speaker at web-related conferences and teaches web design and development at Portland State University. He is a Macromedia Certified instructor and a member of the Dreamweaver Advisory Council.

Unobtrusive JS isn’t for the developer’s benefit–it’s for the end users so that even those without Javascript enabled can access content on your site–this includes search engines as well. If a navigation bar is entirely generated from Javascript, for example, search engines and non-javascript enabled browsers will not be able to access your site.

But, even for developers, unobtrusive JS needn’t be a pain. For example, a Javascript library like jQuery, Prototype or Spry, actually makes assigning event handlers easier than using inline event handlers. Here’s an example with jQuery:

This code preloads any number of rollover images and assigns both mouseover and mouseout event listeners to already existing images on the page. It works for any number of images–if you had to assign inline onmouseover and onmouseout event handlers to each image in the HTML, you’d be keeping yourself pretty busy.

Next, we’ll hear from Nick Crossland. Nick’s been creating stuff for the web for over 10 years, and currently works at Rocket, a web design agency in Sheffield, UK, working on sites for clients ranging from one-man-bands to major public sector projects. I’ve a passion for making things as simple, friendly, usable and accessible as possible. Nick’s digital persona also hangs out at his personal site, nickcrossland.co.uk.

Why is unobstrusive JS a good idea?

It means you don’t have to have an elephant’s memory
Every time you (or someone else working on the site, or a user via Contribute or a CMS) adds in one of the elements that needs the trigger on it, they have to also remember to add the JS trigger to the tag. Are you happy trusting it to your memory? Or the user of the CMS? Or the skills of someone without JS skills as good as yours to put in the code correctly? One error on the page is going to break all the JS on it – not a good move!

It makes naughty scripts play nicely with each other
Imagine you are building a snazzy gallery page of your site, and whenever the user rolls over an image, it should display a tooltip and also a preview of the larger version. Any HTML tag can only have one JS trigger for each event, so you then have to start combining the code from both triggers into one event attribute or function – losing the separation of different bits of functionality, and making it harder to read, maintain and update. Modern JS libraries such as Jquery and Prototype make it really easy to attach multiple events to any trigger, while maintaining that separation.

It degrades your mind
We all know that Javascript reliant applications should also degrade gracefully, so those without JS enabled can still use the site in a sensible way. Seeing the raw HTML without inline javascript is a great mental reminder that the thing still has to work when the JS is stripped away ‚Äì it’s not foolproof, but is a gentle prod that stops you being lulled into assuming the JS will always be there and working.

Otherwise, it’s just getting it wrong
All pedants of the English language know that confusing your verbs and nouns is not only inelegant, but technically incorrect (as anyone who has ever googled someone they want to room with knows). Doing it with the language of web development is no different ‚Äì it will still get the message across, but in a way which will annoy the vocal minority of people (myself included) who like things done “properly”.

Finally, I’ll offer my opinion. I’m honored that Dave and Scott offered to be a part of this experiment. Like my colleagues, I’ve been in software and web development since the early ’90′s. I run a small development studio in Dallas and focus primarily on developing custom systems for small business. I am active in the web development community and, like Dave, participate in the Dreamweaver Advisory Council.

I’ll admit that the first time I heard of Unobtrusive Javascript, I didn’t quite grok the benefit. It smacked of something evangelized by the Propellerheaded Bini-istas that should be done just because it could be done.

I run a small shop and often develop web systems with one or two other programmers at most. Rarely have we needed to work within a large team so I have the luxury of developing in an expedient and efficient way, so my perceptions on this topic are colored with this bias.

I’ve given Unobtrusive Javascript a fair shake. My opinion is that it has some utility. The techniques, for example, prove very useful for a feature that is site-wide such as custom skinned buttons or common navigation features. I by no means argue that UJS shouldn’t be used. I simply believe that a site shouldn’t be considered poorly written or deficient in some way if every JS function isn’t abstracted.

Many argue that separating functionality from content is just as important as separating presentation from content. After all, the benefits of abstracting CSS into common stylesheets has been proven over and over again.

I disagree. By definition, the way the site looks must be consistent from page to page. Therefore, CSS common throughout a site is a must. But the same is not true for JS-derived functionality (for the most part).

Think about your typical use of inline JS. The vast majority of the time, you are triggering some function based on the users interaction with a single object. A button is the best example. If this button appears on every page on the site, sure, abstract it and externalize it. Your user will thank you, and making changes to the functionality is much easier. However, a much more likely scenario is that a single object on a page triggers some unique event. While the code that performs said function certainly should be externalized for optimization and efficiency, going the extra step of removing all of the triggers from the button actually swings the pendulum of efficiency the other way.

For one, it leaves an orphaned button by all appearances. When you open the code later on, you have to dig through external code just to find out what a button does and how it is triggered. For another, the time to implement the external code–assuming you don’t have a tool that automagicallly does this for you–takes longer.

So, in the end, I find that the happy medium is externalizing the functions and classes that are triggered while leaving the inline triggers intact. I’m sure the MVC purists would scoff at this, but then, I’ll be done with my project a lot more quickly than they will.

My goal with this article is to provide different perspectives on a controversial topic. There is no right or wrong answer. Ultimately, your use of UJS must fit into your individual and team workflow. Feel free to weigh in yourself by commenting below.

No, really…stop laughing…they mean it this time. Honest. IE8 will be standards compliant.

Bwaa-ha-ha-ha! Oh, that’s rich! I can’t keep a straight face when I say that. Microsoft really must think we’re idiots. We’ve heard this tune before with IE7. Now we’re in a morass of backwards compatibility.

It would be one thing if Microsoft forced the upgrade to the latest version just as, oh, EVERY SINGLE OTHER BROWSER DOES. But they don’t. So I, for one, am dreading IE8 as yet another browser that I have to support. Build it for Safari and Firefox, and smile. Check it in IE and weep silent tears for the angel that just lost its wings.

Until Microsoft honestly and truly dumps their coprporate mindset of dragging the last 10-15 years of technology along with backwards compatibility because some fortune 500 IT department doesn’t want an upgrade is ridiculous. Nay, reCOCKulous.

Now, I hope I’m wrong. Let’s hope the 8th time is the charm.

I actually started this post for a reason. Ars has an interesting article on IE8′s standards compliance. Check it out here:

Wisdom and folly: IE8′s super standards mode cuts both ways

I’m an avid user of Google Reader to handle my two dozen or so feeds. Among my favorites are Boing Boing and CNet. However, I’m thinking of removing them from my list.

Why? They all publish too many stories to possibly keep up with. Which begs the question: how many updates per day is too many?

In the case of CNet, there have been days when they’ve published over 100 stories. My thesis is that this information overload results in an unused feed, making users drift away from your site.

For an RSS feed to be effective, 10 updates a day seems to be the magic number. This is opinion, not fact, but I would imagine that I’m not the only RSS consumer who feels that the sweet spot is somewhere south of a ten-spot.

This assumption is based upon the belief that a feed shouldn’t be a fire hose of information, but rather the delightful stream of mountain spring water that is the distilled information you care about. (Forgive me. I just can’t help myself sometimes.)

So what can be done if you’re developing a content rich site that will be updated dozens of times a day? My typical solution for clients is to provide a variety of granular feeds that filter the content such that feeds have no more than 10 updates a day.

Take, for example, Boing Boing’s iBag feed. What would be great is a set of specialty feeds that filter out, say, all stories on Steampunk, old scans of magazines, or Xeni’s long travelogues. What would be left are the few nuggets of info I actually care about.

Looking at one of my own sites, McKinneyNews.net, we offer a ton of RSS feeds. You can drill down by sport, school, writer, or any combination thereof. This reduces the total number of daily updates to a digestible number.

Another good example is Wired’s menu of choices. You can drill down by subject and author. They even allow you to create your own custom feed based on news you care about.

These examples share one thing in common: they let the reader scan and consume content they care about rapidly. This creates a stickiness that makes your site a part of your reader’s daily info diet, which is good for your client and good for your business.

Ages and ages ago when I started coding for the web, I read somewhere that it was more secure to keep the file containing your password and sensitive variables outside of the public web root. I’ve always taken this as law, and I’ve jumped through all kinds of hoops to structure my sites and framework in this manner.

But is it necessary? I’d love your thoughts on the matter.

For Dreamweaver users, this is important for two reasons: 1) the Connections folder is placed automatically in your site definition’s file root, and 2) Dreamweaver freaks out and breaks in all kinds of new and interesting ways when the file root and the public web root are not the same.

If I’m jumping through all of these hoops unnecessarily, I’d like to do something about it and stop banging my head against a wall.

To clarify what I mean, let’s take a linux install where the home directory is “/var/www”, and the public web is served from “/var/www/html”. In this case, you’d set the Dreamweaver file root to “/var/www”. Thus, the Connections folder is kept outside the public web root. In theory, there’s no way this folder could be hacked through human/webmin error (forgetting to turn off apache indexing, for instance), or through some other means.

So my question to you, my loyal readers, is whether this is necessary. What are the implications to keeping the Connections folder inside the public web root? Do you consider this to be dangerous, or am I worrying unnecessarily?

Thoughts? Discuss.

The old adage, “If it ain’t broke, don’t fix it,” applies when it comes to Leopard’s new Stacks feature. Stacks has been highly touted by Apple to be a boost to productivity:

Organize files in a neat stack on the Dock.
One click and the stack springs open,
revealing items in an elegant arc or an
at-a-glance grid. [link]

Nothing could be further from the truth. I believe that Stacks fails in every way to enhance productivity.

Illustration 1: Poor User Interface with Changing Dock Icons

1. The dock icon changes as the contents change (see above). From a UI perspective, this is a bad idea that simply works against the user’s ability to act without thinking. Instead, he/she must roll-over each Stack and read its name to differentiate it from the other Stacks in the dock.
2. The Stack, especially in grid mode, truncates file names (e.g. “My Scrip…s.txt”), making it nearly impossible to differentiate one item from next (see below).
3. An open Stack takes up far too much screen space (see below). The user just needs a hierarchical menu of file names, not preview-able icons.
4. The user can’t navigate into sub-folders, forcing her to open the Stack’s finder item almost invariably.
5. While Apple may consider the leaning stack to be “elegant,” the reality is that this makes it very difficfult for the user to quickly scan the folder’s contents.

Illustration 2: Unreadable, truncated file names and useless icons

In other words, the Stacks feature fails in every way to make it easy to click and select an item. The old method that let me dock a folder and right-click to view its contents was perfect. Why change something that wasn’t broken? The new Stacks feature may demo the OS well, but it is useless in a real-world production environment.

In the hope that David (one of Apple’s customers) can beat Goliath (Apple), I have written an open letter on this topic imploring Apple to bring back the old hierarchical menus for dockable folders from 10.4. If you agree with this letter, I encourage you to add your voice by commenting on it in the Apple forums.

[Update: 11/04/07 4:15p] The open letter described above was pulled from Apples Discussion Forums 42 minutes after it was posted. I’ve moved the Open Letter here. If you agree, feel free to post your comments below.

The following Open Letter was deleted from the Apple Discussion Forums 42 minutes after it was posted.

I understand the need to control your message and keep a lid on bad PR, but if this is a trend that continues, I think Apple is heading for trouble. Biting the hand of your customers–especially those of your evangelists–is no way to do business, in my humble opinion.

Dear Apple,

To be blunt, the new Stacks feature is useless. On behalf of the legion of users and fans who upgraded to Leopard, I implore you to give us the ability to turn off Stacks and return to the 10.4 method of docking folders.

There are several reasons Stacks fails as a productivity enhancer:

1) The dock icon changes as the contents change. From a UI perspective, this is a bad idea that simply works against the user’s ability to act without thinking. Instead, he/she must roll-over each Stack and read its name to differentiate it from the other Stacks in the dock..

2) The Stack, especially in grid mode, truncates file names (e.g. “My Scrip…s.txt”), making it nearly impossible to differentiate one item from next.

3) An open Stack takes up far too much screen space. I just need a hierarchical menu of file names, not preview-able icons.

4) I can’t navigate into sub-folders, forcing me to open the Stack’s finder item almost invariably.

5) The leaning stack forces me to tilt my head just to read and interpret its contents.

In other words, the Stacks feature fails in every way to make it easy to click and select an item. The old method that let me dock a folder and right-click to view its contents was perfect. Why change something that wasn’t broken? The new Stacks feature may demo the OS well, but it is useless in a real-world production environment.

Please provide an option to revert back to the 10.4 method.

Many thanks,
Steve Stringer
Web Developer
Dallas, TX

http://developer.apple.com/iphone/