Tuesday, March 20, 2007

Web Programming, Hobo-style

Today I embark on a great journey.

I've been reading about Ruby on Rails since my buddy Jeremiah recommended it. I really wish that I had spent some time up front getting into the Ruby language and the Rails framework, because it would have saved a huge amount of time on some of the projects that I've been working on over the last year. I finally decided that it was time to really dig in and learn the ropes, and started by watching the Ruby on Rails screencasts. In a word: Wow! All the great stuff that I had heard about Rails was true. It was just what I was looking for: a standardized system designed to handle all of the repetitive, tedious tasks that go along with building web applications, like creating data objects with dozens of properties to match your database columns.

I installed Ruby on my Windows XP box with no trouble using the one-click installer. But when it came time to install Rails through the gems package manager, I got an error at the end about how it couldn't auto-generate some bit of documentation. Then when I tried starting up a test WEBrick server, it bombed out with an error.

It turns out that there is a bug with the current Ruby Gems package. The instructions that I found didn't quite work, but here's what did:

  1. gem env

  2. In the output from "gem env," find the GEM PATH directory, go there, and delete the "source_cache" file from that directory.

  3. gem update
    If it asks you what to do with any specific gem package, just skip it and finish.

  4. gem update --system
    Although this would seem to be the logical step after deleting the source_cache, I found that it produced this error:

    ERROR: While executing gem ... (Gem::GemNotFoundException)

    Could not find rubygems-update (> 0) in any repository

    But running "gem update" first, and then following with "gem update --system" fixed it.

  5. gem install rails --include-dependencies
    If you get an error that the rails gem is in an invalid format, try running "gem update rails" instead.


At this point, I got the message "Successfully installed rails-1.2.3" and I was good to go.
Booting WEBrick...

Rails application started on http://0.0.0.0:3000


Here's the rest of the Ruby on Windows installation process

Tuesday, March 13, 2007

Why to choose CSS over table-based layouts

Not too long ago I was asked by a designer colleague, who was still figuring out the whole HTML design process, "So, why do we have to use all of this CSS positioning stuff to lay out this page? Why not just use tables?" The short answer that I gave her was basically that tables aren't accessible, and since we design sites for government agencies that are mandated to have accessible websites, we can't use tables. She then asked, "Why aren't tables accessible?"

I had to give that one a little bit of thought, but then I explained screen readers and linearization and all of that. How when an older screen reader looks at a page, it reads it from left to right, top to bottom, just like a human would. But it doesn't know that there's a table dividing the page elements, and so it reads across cells before continuing down into the next row of text, often combining parallel text from adjacent cells. This results in nonsense speech, which, as you can imagine, presents a problem.

So she went on her way, digging into the CSS positioning tutorials once again. A few weeks later I got to thinking: if an older screen reader reads text linearly, and a page is laid out using CSS positioning, then wouldn't there still be a problem? For example, if a navigation column is floated left of the body content, wouldn't a screen reader read left to right, seeing a navigation link and then a line of body text, and so on? This just didn't seem right, and it made me start thinking again about accessibility.

The answer that I came up with was pretty simple: Turn off the CSS to see the accessible version of a page. You can usually do this in your web browser, for instance in Firefox you can choose View : Page Style : No Style. Then, the browser falls back to rendering the HTML as the W3C intended. Everything comes out in block order, starting with the first tag in the body and continuing to the end of the body tag. Nothing gets laid out side by side, except for tables (which, of course, should only contain tabular data!) And if you're putting design graphics into background-image properties, they'd disappear too, leaving you with a nice, clean, accessible version of your page. Naturally, if you were to lay out a page with a table-based layout, and then look at it without CSS turned on, you'd still see your circa 1996 table layout in all its boxy glory.

If you have trouble getting your browser to disable CSS, try visiting CSS Zen Garden, check out how the page is laid out, and then click on the "Download HTML Source" link to see the unstyled HTML source. Looks quite a bit different, eh? Much more simple and to the point, but also without the emotion of the graphic design. Fortunately, screen readers don't do such a hot job of synthesizing speech with emotion, as far as I can imagine.

There is, of course, a standard objection to this motive: if a user disables CSS, then all of your effort designing the page is for nothing, but if you do it with tables and bgimage attributes then they're stuck viewing your genius, and who cares about accessibility anyway? There are lots of reasons to make your design accessible: more visitors can view your site, which means that most likely more visitors will view your site than would otherwise. Afterall, you don't want the pool of visitors who will link to you to be limited only to sighted people. Also, keep in mind that Google is visually impaired. Google doesn't care how interesting your design is. It cares more about the words on the page, and how difficult it is for it to get at those words, including how much non-content markup it needs to parse through in order to extract the content. By removing the table, row, and cell markup, you're vastly reducing the file size of your HTML and offloading that payload into a separate CSS file, making it easier for the search engines to access your content, which makes them as happy as an artificially-intelligent agent can reasonably be, and quite possibly improving your page rank. I should add that human visitors will also be happy with the reduced file size, since they only have to download the CSS file once and have it apply to every page on your site, whereas a table-based layout bloats every page.

Labels: