Crystal's Adventures in Webdev Land » html

Teaching HTML as a Second Language (HSL)

Crys — Thu, 11 Jun 2009 16:43:31 +0000

…is hard.

A major project I’m doing right now at work involves teaching HTML/CSS and (and probably Javascript) to an audience of mixed knowledge-levels.

Now, I’ve got a lot of experience explaining things in context and answering questions for people of different levels of computer literacy. And I used to tutor students in Math, Science, English and other languages, and I taught Art privately for awhile. So no problem, right?

Trying to condense an entire introductory class into a couple hours and make it both appropriate AND useful to all different skill levels and then use it to contrast against the html/css/javascript being written by a tool provided by a vendor? Ouch.

I’m thinking that it might be best approached as exactly what it is: a foreign language. It has its own alphabet. Its words are elements, and it most definitely has its own rules of grammar. The doctype tells a browser what dialect you’re speaking in (html and xhtml are about as different as American and Britsh English, for instance).

Form Usability and Design

Crys — Tue, 26 May 2009 19:41:42 +0000

Most of the work I do right now, I can’t post here because it’s proprietary and client-facing only. However, there’s one application, Mortgage Loan App, that’s fairly new and is what we call a “consumer facing” (meaning our clients’ customers) application that I would like to use as an example to discuss usability in forms and other aspects of form design. I’ll be referring back to it quite a bit in the next couple weeks. This copy is our production environment test copy; clients can customize the application with their own logo, colors and contact information.

A few forms topics (will link each when the post is finished, so feel free to bookmark this page to make it easy to find them in the blog):

Label Placement
Row Highlighting
User Flow
1. Tabbed Interfaces meet the Wizard
2. Back/Next Navigation
3. Button Placement
4. buttons vs input=button vs input=submit
5. Information breakdown, what’s on which page and why
Why I use unordered lists in fieldsets for my forms
Progressive Enhancement and Usability:
1. dynamically hiding extra fields when they aren’t needed
2. Making your form usable even when js and css are turned off by the user
Making it Pretty
1. CSS file design for multiple templates/themes
2. Nifty 3d buttons without resorting to graphics
3. Disabled Submit Buttons in IE and Firefox
4. IE and empty divs

View Javascript-Generated Code in Internet Explorer

Crys — Tue, 26 May 2009 16:23:42 +0000

If you’re using the Web Developer Add-on in Firefox, you are probably already familiar with the “View Generated Source” option (Web Developer > View Source > View Generated Source) for use in debugging code that is manipulated by javascript. But what do you do in Internet Explorer, where no such option exists?

Here’s my solution:

1) Go to the page whose generated source you want to view. Let it load in its entirety.

2) Put this in the address bar (broken to two lines to fit in my page’s width. Should be all on one line with no spaces for browser):
javascript:'

'+window.document.body.<br />
parentNode.outerHTML+''

Your page will be replaced with the current state of the DOM, as Explorer sees it. xmp is a deprecated html tag that treats all the characters between the start and end tag as text instead of reading it as html. Since you can run javascript from the address bar, you can just take the whole page, put it between xmp tags, and spit it back out again. This is especially useful if you’re using browser-sniffing js to serve different js code to different browsers, because you otherwise would be unable to see the js in action in IE.

Note that this only works in Explorer, but that’s ok. If you want to see it in Firefox, it’s built right into the Web Developer’s Toolbar, or you can use innerHTML instead of outerHTML to get a similar output. The Developer Toolbar for Explorer is less reliable for viewing generated content; my experience is that it tends to get caught on a cached version of the DOM, so this trick is invaluable when you want to see the same page before and after events on the page have changed the DOM.