If you’re anything like me, you’ve used the alert message function as a means to figure out where things were falling apart. That’s great and all, except that it sucks. I hate needing popup messages to debug things like mouseovers. It’s no fun. If you forget to pull one out of your code before it goes to production, it can be miserable trying to track it down later when users are getting alerts that say things like “Why doesn’t my function work??”

Whoops.

So, I started thinking about developing in pretty much any other language out there, but mainly Java since I have to touch that only slightly less than I touch PHP scripts. Java is great because you can output directly to a console, so you can log stuff and watch as the mayhem unfolds while your program bombs. It’s REALLY helpful.

SO…

I decided I wanted a console I could output to at any time. Something I could review on the fly and see what is happening. This would allow me to review any logged output I wanted in real time, and I could avoid the alert box altogether. Hmm… what could I output to? The DOM!

Right??

I sat down and cranked out a handy dandy script that will write to whatever div you decide to use as a console. If you are lazy, like me, then it will also do something really spiffy and just append a console to the end of your document.

The nice thing is you can just define a console div and write to it. When you send your code to production, you can just style your console with display:none. If you forgot to pull a write statement out of your code somewhere, the world won’t come to an end, and your users will be none the wiser. (For the record, I still strongly encourage you to NOT leave test code in your production code. This is just a CYA measure.)

So, where is this code and what do you do to make it go?

Let’s start with the “making it go” part first. Include the script in your code, I’ll give you a link to the file in a moment. Then add this line of code to your document:

var ow = new OutputWriter();

Tadaaa!!

You now have a console on your page you can write to. If you want to write to the console for whatever reason, it goes a little like this:

ow.writeln(“your message.”);

If you made your own console, and you want to write to it, then instantiate the writer thusly:

var ow = new OutputWriter({ consoleId: “your_console_id” });

There are other things it can do as well, like clear the console:

ow.clear();

Store and retrieve cleared history:

var ow = new OutputWriter({ consoleId: “your_console_id”, storeHistory: 1 });
ow.clear();
var history0 = ow.gethistory(0);

You get the idea.

There are more parameters you can set too. I put them all in the comments at the top so you can decide what to use and what to skip. They are all 100% optional, so don’t worry about it if you don’t want to set them.

So, on with the script, already! Just download this one little file and you have everything you need to do all of the console-writing magic I described and, potentially, more. Debug your code with grace and style and make the web a better place.

©2012 Chris Stead. All Rights Reserved.

Ultimately, it is rarely clear where boundaries are in a project. What is too much, what is too little? Somewhere between too much and too little is just right, much like what Goldilocks wanted in her porridge. We know that even the most limited of users should be able to access our sites within certain considerations. A photo gallery is, ultimately, little use to a blind person, but alt tags should still be in place. Sound clips of the Boston Philharmonic Orchestra would be useless to a deaf person, though a caption or indication as to what each sound clip is would be quite handy.

Coming back to the point, finding a balance point is critical to providing rich, meaningful interaction between your user and your site. Perhaps the first question which should be answered is “can this be done without Technology X?”

Technology X is always the hot technology everyone is dying to use. Flash, AJAX, CSS3, these all have fallen under the Technology X heading at one point or another. By using Technology X as your baseline interaction, you may be causing your users pain when you thought you were enhancing their experience.

A prime example of where Technology X is used when standard interaction would do is the Google login procedure. Many, if not all, of Google’s login boxes use AJAX for verification of user creds. It sounds cute and looks vaguely neat, but what happens when the browser barfs on their Javascript or you suddenly lose your internet connection? You have no clue what happened.

Your experience just took a nose dive and left you in the dark.

This is especially bad news for something like a login. Logging into a website should be a simple, straightforward, FAST experience. I want to type my creds, log in and be on my way to my dashboard. If something dies unexpectedly, I want a clean, clear indication as to what happened and why. If someone cut my ethernet cable in the next room, I want to know my computer lost network connectivity and that’s why I’m not seeing my dashboard in all its glory.

CSS is another item which can choke on users, leaving them feeling lost and confused. When things are hidden or altered with CSS in a way that makes them unreadable or unusable to the user, it can get ugly. The user sees a damaged site and moves along. Your rep falls to pieces and your user has moved on to greener pastures. This is especially true for people using Javascript to reveal something hidden with CSS.

The phrase “if it is to be shown with Javascript, hide it with Javascript,” carries a lot of weight with me. If your Javascript is going to die, it would be preferable that you err on the side of caution. Show everything. Make sure the page is as usable as possible.

So, the balancing act. I’m not saying there is no room for Technology X. The Technology X of today is the old standby of tomorrow. People will become familiar with new technology and learn to expect it. In the meanwhile it is important to consider what your user is aiming to do.

As a friend of mine likes to quote: Proper prior planning prevents piss poor performance. Know what it is your user is trying to accomplish by using your site. If they are there to purchase widgets, build a no-frills site which sells widgets. Use styles only to make the page more readable. Make sure everything makes sense without styles. Don’t use Javascript to do anything. Let the server do all the grunt work.

If you plan your site carefully and build something which is clear, usable and meaningful, adding Technology X will only make the site better. If something fails, your user will still be able to interact with the site and get things done. It may take them an extra click here or there, but it won’t be the show stopper it would have been if Technology X had been your only approach.

Balance is everything. Balance your plain site with your desire to incorporate interesting new technology. Just because it might be neat to see something done with AJAX doesn’t mean you should. Flash doesn’t solve all world ills. Sometimes a little bit of HTML a dash of simple CSS and some server-side elbow grease will do just fine. Build your sites for real use. Make your toys secondary. Think about your users’ goals and make the web a better place.

©2012 Chris Stead. All Rights Reserved.

Engineers and designers work together, or divided as the case may be, to create an experience that users with all of their faculties and a modern browser can enjoy. While this goes down, the rest of the world is left feeling a bit chilly.

What happens is, the design starts with the best of intentions and, then, the interactivity bug takes hold. What comes out is something that is almost usable when slightly degraded, but totally non-functional when degraded to the minimum.

In the end, of course, the user needs must be considered. Having a graphically intensive site doesn’t hurt if you are a design firm, but might not be the best option for a company dealing with medical customers.

My suggestion, however, is simple. Instead of degrading your site as the user needs become greater, start with a site that is usable at the lowest common denominator and work up.

Understand who your audience is and prepare to serve those of them who have the greatest needs. Build a site that is attractive and works if the user can only view it through a program that reads for them.

Once your site has been built and is fully functional, build up. Integrate functions to serve the users that have some needs, but aren’t in the highest-need area on the spectrum.

Continue on this path until you have integrated all of the latest and greatest, bleeding-edge functions that your highest-ability users can interact with.

As you build this way, be sure that you are simply enhancing the function that is already on the screen. As you add enhancements, you should be able to remove them cleanly and still get the same experience you started with.

I call this approach graceful integration. Each progressive step, you integrate more functionality and interaction, preserving the layer just below as a separate user interaction.

Each progressive enhancement should be separate and easily disabled. The granularity of your enhancements can be as large as a two-step approach: all or nothing. You may also enhance your site in a careful way that allows for several levels of degradation depending on the user and their distinct needs.

A natural separation of user interaction happens when HTML is written, CSS is added and Javascript acts upon the subsequent design. This three-tier separation, you can use the work that will be done regardless to define your user interaction in a clean way.

One of the best quotes I’ve heard regarding graceful degradation, in paraphrase, is, “if you show it with Javascript, hide it with Javascript.” I offer this with no source as I can’t recall where I heard it. If you know/are the author of this, stand up and reap the rewards.

The attitude in this quote represents the core of graceful integration. As you pile the Javascript on, be sure you manage its behavior with Javascript. Don’t use CSS to manage something that is going to be handled with Javascript. If you must, prepare a style sheet that defines scripted behavior, but set the object classes with Javascript.

There are other benefits you’ll gain from this approach. Not only will your users appreciate the time and care you put into their experience, so will the search engines.

As search spiders crawl your site, they won’t see any CSS that looks to be doing something sneaky like hiding text from the viewer. Spiders have gotten smarter and they recognize when something fishy is going on. As you are already doing something good for your users, you get this bonus for free.

For those of you looking for snippets of code, the best thing you could know and rely on is the “noscript” tag. This is a tag which defines the behavior of the page for users without Javascript. I use this quote a bit to display extra form controls when Javascript has been disabled or is unavailable to the user. You can use it like the following:

<script type=”text/javascript”>
//your script logic goes here
</script>
<noscript>
<!– HTML elements go here like style definitions or form controls. –>
</noscript>

You can also use noscript by itself scattered throughout the page to display page elements that might, otherwise, be missing for some of your users.

In the end, behavior on your site should be defined by the HTML first, the CSS second and the Javascript third. Should you choose to go to a finer granularity, don’t forget to double check your users can still use all of the layers effectively. Be mindful of your users, integrate function into your site in stages and make the web a better place.

©2012 Chris Stead. All Rights Reserved.

This site, which shall remain unnamed, commits one of the greatest usability crimes I’ve seen: they rely only on Javascript to submit their search. In order to give you, dear reader, the scope of the issue, I always test sites like these by disabling Javascript and testing the function again.

The search stopped working.

Mind you, if this was some sort of specialized search geared toward people that were working with Javascript technology, I might be able to see requiring Javascript in order to make the search work properly. Even in circumstances like the aforementioned search, shutting down the search with Javascript disabled is still questionable.

This, however, is a search for local pharmacies.

Considering the users that might be searching for a pharmacy, we can compile a list. This is not comprehensive: the young, the elderly, the rich, the poor, sick people, healthy people, disabled people and blind people. I’ll stop there.

Let’s consider a couple of select groups in that list, i.e. the poor, the disabled and the blind. The less money you have the less likely you are to buy a new computer if your old one still works. I know this sounds funny, but I’ve seen people using Internet Explorer 5.5 to access sites in the insurance world. Lord knows what other antiques they might use to access a site. Suffice to say, people with old computers may not support the AJAX calls made by an AJAX only search.

Let’s, now, consider the two groups who are much larger than the IE 5.5 crowd: the disabled and blind. I separate these two so we can think about different situations for each.

First, the blind. Blind people use screen readers to view web sites. Though I am unsure as to the latest capabilities of screen readers, but the last time I did reading about screen readers for the blind, I was brought to understand that their experience is a little like using Lynx. See a screencap below to get an idea of what Lynx is like.

ChrisStead.com on Lynx

As you can see, browsing for the blind is kind a no-frills venture. No CSS, no Javascript, no imagery. Since many of them can’t see what you have made available, (yes, there are varying degrees of blindness) they have to rely on a program to read the screen for them. This means, pages that rely on Javascript for core functionality are out of reach for these users.

In much the same way, disabled users may have a limited set of functions they can access within their browser. This will depend on the degree of disability and the breadth of function on their browser. I can’t and won’t say what a disabled browsing experience is like since I am not disabled and the experience varies so widely it’s not possible to pin down what the overall experience is like. Suffice to say, it is limited.

Now, the reason I mentioned the site was built on ASP.Net: For whatever reason, the sites I see with the worst usability almost always seem to be built on ASP.Net. I have a hard time wrapping my head around this, as I’ve built ASP/C# apps and had no problem building the core functions to operate with or without Javascript enabled. Everything you need is right at your fingertips.

From sites that require users to be on a windows machine using the newest version of Internet Explorer, to web apps that require users have Javascript and images enabled just to navigate the core functions, ASP sites often seem to be bottom of the barrel.

Perhaps it is a group of people that are used to developing for desktop apps and haven’t had to consider usability in the modern age of the web. Perhaps it’s novice developers that don’t understand some of the core concepts that go into building successful web applications. Either way, the current trend of ASP disabled-inaccessibility must come to an end.

To the ASP.Net developers of the world, I implore you to reconsider your development goals and meet the needs of your customers. To the rest of you that may be committing the same sins in another language, I beg you to be considerate of all of your users, instead of a select group. Think about usability for a degraded experience, build accordingly and make the web a better place.

©2012 Chris Stead. All Rights Reserved.

Let’s talk about HTML and XHTML. These are both derivatives of SGML which is a generalized markup language that is used to describe data. That’s it. SGML doesn’t make things “look” a certain way. You won’t find it hanging around the local bar trying to pick up girls. It’s just data description. Kind of geeky, like that kid that sits in the back of class playing with his… calculator. So, then HTML was developed with it’s own DTDso that people could describe the information contained in their HTML documents.  Early HTML was easy to interpret if it was coded well, however most people are sloppy with their code.  This led the W3C to create a code validator.  Now, based on the DTD that you use your document may be standards complient or it may not.  Personally I really like to stay within the bounds of strict XHTML, though onMouseOver is deprecated, so Javascript kind of hoses the whole complience thing.

This leads us to the topic at hand: accessibility.  Considering that HTML and XHTML are used for simply describing data, why would a page be more or less accessible?  Well, let’s think about that kid that has MS, but still needs to get online research done for a class he’s taking, or better yet, consider Stephen Hawking.  Do you think that they would be particularly amused if they had to fill out a form and had to be pixel precise to click on the input field?  I promise you they wouldn’t.

Accessibility means that regardless of the browser or disability, your page should still be reasonably functional.  Now, this does not mean that your page should read minds, but there are some tags that should be very familiar. Learn and use the following:

<acronym> – The acronym tag describes what an acronym means.  Hover your mouse pointer over the first instance of HTML, XHTML, SGML and DTD.  The full name will pop up.  In some screen readers the full text will replace the acronym so that the human can interpret what the acronym means.

<label> – Label tags should be used with form inputs whenever possible.  This will ensure that your user will be able to click on either the form element or the associated text and the form element will gain focus.

<noscript> – Ok, if you have ever used Javascript, you are familiar with the <script> tag.  So, in contrast, the <noscript> tag surrounds what should happen if Javascript or other inline scripting language is disabled.

Aside from these few tags, you should also become familiar with the following attributes:

title – Title can be used on practically any element.  This should be used somewhat sparingly though, as using a title with an alt tag, for instance, could spell disaster for a screen reader which cannot interpret all of the attributes precisely as you might expect.

alt – EVERY IMAGE SHOULD HAVE AN ALT TAG!  No ifs ands or buts.  If the image is included in the page via the <img> tag, use an alt tag.  Furthermore, use descriptive alternate text.  img_21938740928374.jpg is not useful.   I will find out if you are doing this and I will stalk you in the night.  Alternate text doesn’t have to be perfect.  No two people are going to interpret it in precisely the same way, but if the image is of a bird in flight, use alternate text that says something like “bird in flight.”  People will understand enough to get by.

accesskey – The accesskey attribute sets the stage for people that are going to use the keyboard to navigate your site, or perhaps have a limited command set to work from.  This attribute enables people to use keyboard shortcuts to access form elements for their ease and convenience.  I recommend using this tag in your forms in general, though I strongly urge you to add accesskey to any form elements that a disabled user might be looking to use.

Moving forward, let’s discuss the <noscript> tag.  Whenever you have a Javascript effect on your site, consider whether there would be a problem if there were no Javascript enabled.  As a matter of fact, go to your site, turn off Javascript in the options and try navigating.  If your site topples like a house of cards, you need to re-work your Javascript.  I currently work for a company whose previous web-person didn’t account for people with no Javascript.  The corporate site is totally unnavigable without Javascript.  This is bad.  This is really bad.

Ensure that your scripts degrade gracefully.  If you have elements that are hidden from the user until the Javascript function is triggered, what happens if scripts are disabled?  I always run a special function at the end of the page that hides the elements I want hidden.  What this translates to is, if you have scripts disabled, the page displays everything.  The failsafe for my scripts is usability.

This brings us back to Lynx.  Don’t think that I had forgotten.  I browse my sites using Lynx.  I do this so that I can see what happens when nothing is viewable but text.  Lynx doesn’t even give any particular kind of formatting.  Pages are just a long string of words.  If you can open your site like this and still find everything easily you have successfully made your site accessible.  If your page looks like an amorphous mess then you have some work to do.

Now, go forth and make the web a more usable place.

©2012 Chris Stead. All Rights Reserved.

Scope: A mouthwash.  Yep.  There you have it.  Brush and floss every day and you’ll be a better programmer.

That’s useless.

Scope: In computer programming in general, a scope is an enclosing context.

Ok, at least this one is accurate, though it doesn’t tell us a whole lot.  Really, the way that you can look at scope is “what parts of my program can access this element?”  I know that “element” is a little vague, but you can have scope that refers to objects, variables, functions, classes and a whole set of “elements.”  You see why I chose the word.  What I am concerned with here is the scope of a variable.

So, how do we reconcile this in programming terms?  Well, a variable can be a global, i.e. it can be accessed by anything.  Global variables are bad and should be eliminated with impunity.  I recommend a pistol.  Seriously, though, if you have a global variable that is storing anything that might be more than garbage text, you should probably find some other solution for your data storage needs.

Object scope.  This is much more limited.  Generally in an object you want to kind of tuck the variables away so that people don’t fool with your program.  Anything that is tucked into an object and set as private or protected will serve you well, grasshopper.  With any variable that is private or protected in an object you’ll need to write a get and a set method/function for it.  Just something that should be said

Function scope and finer grain scope.  Variables that are explicitly defined in a function are available to the entire function from the definition of the variable onward.  Variables that are defined in a for loop, though, are available only in the loop.  This being said, if you define a variable for use in a loop like so “for(var i=0; i<…” the scope is limited, however if you define a variable as such: “while(true){var i=0…” then ‘i’ will be available outside of the loop, in other parts of the function.  This is a very important distinction.

Quick thoughts on “while(true)…”  Don’t do it.  Seriously.  Bad idea.  Bad bozo, no cookie!

So, now the problem that I ran into.  Javascript will allow you to declare a variable thusly: “i=5″ and it is fine with that.  If there is no prior instance of the variable ‘i’ then a global will be created.  If there is a prior variable that is accessible, it will overwrite the current value of ‘i’ as it should.  If there is a variable ‘i’ that is limited in scope and inaccessible by the current operating function, a global will be created.  This is important to know when you are doing things like writing recursive functions.

Recursion leads us directly to the problem I had last night.  I was working on a recursive function that had a loop with an incremental counter.  I just went with “for(i=0; i<other_var; i++){…”  I seemed to recall that if you declared a variable this way you would still have a nice, tight little for-loop scope to work with and you wouldn’t interfere with other functions or instances of the recursion.  I was wrong.  This kind of error is somewhat invisible.  This took a while to figure out.  The way I should have done, and ended up doing this is “for(var i=0; i<other_var; i++){…” Please note the added ‘var.’  This will fix the scope issue and my code ran without a hitch.  Fun!  So, with that in mind, kids, remember to scope your variables properly or you might find yourself in a sticky situation.  Good luck and good web work!

©2012 Chris Stead. All Rights Reserved.