Review of "Learning Website Development with Django"

The book’s subtitle, “A beginner’s tutorial to building web applications, quickly and cleanly, with the Django application framework,” frames the book perfectly. Its target audience is programmers (moderately) familiar with Python, but who are, at the same time, new to Django. The book is really focused towards this audience. The other key word in the subtitle is “quickly.” This book moves along in a hurry while creating the demonstration app. I was quite comfortable (and pleased) by the pace, however, I can imagine that a more novice programmer may have a harder time dealing with the information flying by.

The book centers on building one app, a social bookmarking website similar to del.icio.us, or ma.gnolia. I think type of site was a good choice, since it provides the author with a varying degree of complexity to play around with. It allowed Mr. Hourieh to start with the basics. This book succeeds in starting simple and getting harder as it goes along. I also thought it was good to focus on creating just one website, rather than a bunch of mini-projects or examples, since it models a more real-life situation. The idea of a social bookmarking website, as well, is very useful because its features are currently en vogue, and can be found on many current sites.

Chapters One and Two are the obligatory “what is Django” and “how to install” chapters. The meat of the book starts in Chapter Three when the project is introduced. By the end of this third chapter, we’ve already quickly written three database models (Links, Users, and Bookmarks) and the main page. Chapter Four introduces Django’s built-in user authentication system (django.contrib.auth), and describes how to write login, logout, and registration pages. Chapter Five instructs us to write an additional database model (tags), which is more complex than the models we wrote previously. Here we also write pages to display the list of bookmarks, bookmarks by tags, and a tag cloud. [To illustrate how fast we’re moving, Chapter Five ends on page 91]

it's about time

I have no time for anything!

This is how I usually feel. There are so many things in the world that I want to do/know about, and yet they all take time to do/learn. I don’t have any big to-dos that eat large chunks of my time either… I work, I have my orchestra, I eat, and I relax. I try to use relaxation time for learning/discovery (when I can, of course). It is just very hard. I haven’t taken an analytical approach to the problem yet, but I think I should sometime soon (of course, that may take a while to get to.)

I don’t often rely on calendars, I may have to start. I don’t feel like people ‘rob’ me of time, but I think I should pay attention to that. And of course, I am always trying to make my learning/doing time more efficient (that’s the only thing I have down pat).

Ok, enough rant. Now just a little tip-of-the-hat to what I’ve missed recently… the FringeDC Meeting, the Refresh DC Happy Hour, the first Refresh Baltimore Meeting AND planning group, as well as my books, especially the Web Navigation, RESTful Services, Graph Theory, and Discrete Math books! (This is not to mention the projects I’d like to get started!)

Maybe I’ll just win the lottery. That may buy me some more time.

Using the label element for form accessibility

I’ve always been a fan of the <label> element. It’s an incredibly simple way to make a form more accessible. It does two things:

• It explicitly associates text with a form element, so a screenreader doesn’t have to guess what text goes with what form element.
• For checkboxes/radio buttons, it gives the user a larger click area, which is useful for people with limited vision (or me, since I always end up missing them!)

You can find a number of simple usage examples on the W3C’s WCAG Techniques page for labels.

I recently discovered something new about the <label> element (new to me). I hadn’t realized that you can associate multiple labels to one form element. This is useful because it allows you to associate even more information with a form element. With it, I could write something like this:

<label for="box">1. </label>

<input type="checkbox" id="box"/>

<label for="box">This is some text with a 

<abbr title="full title name">shrt. title</abbr> other stuff inside.</label>

This isn’t the most useful example, but I think it demonstrates the general idea. [Note: normally, I wouldn’t write out an explicit number, I would use an unordered list. But without major support for CSS counters, I find myself between a rock and a hard place.] My optimism was quickly quashed though, because, as Roger Johansson mentions, screenreaders tend to ignore two labels. I will have to do some of my own testing to find out more, but I find this very disappointing.

Another interesting application is to include labels for screenreaders, while using CSS to hide them from visual users. Just make your label a block element, give it a 0 width (to remove the width it would have taken in the document flow), and move it off-screen. You cannot simply display: none the label, as that usually hides it from screenreaders. I would like to look further into the end result using current technology (hoping for improved results since 2004), but I certainly believe this leaves no excuse for anyone NOT including labels in their forms.

Back to using one label again, I ran into a Firefox Bug where a link is included in a label element. When a link is clicked inside a label element that is associated with a checkbox, the checkbox becomes checked! Hit the back button, and the item will still be checked, with the visual check the only evidence anything happened. You can see how this would not be friendly to a screenreader (not to mention visual users!) IE and Opera both behave without checking the box. If you have a moment, please vote for this bug and help me get it fixed.

Big release day on the webbernet

So I guess it’s simply the time of year. Many big releases today… software, APIs, and more!

First, the biggest. IE8 has been released in initial beta. The release was also included a general overview of IE8’s new features and fixes. It’s actually quite a lot of information to absorb all at once. I’ve skimmed a number of the IE8 whitepapers, and feel the biggest changes are W3C’s WIA-ARIA support, Acid2 compliance, the javascript selectors api, and their assertion of achieving CSS 2.1 compliance. Of course, the devil is in the details, and there is no company for which that statement is more true. They have a lot of work ahead, and we know they talk a good game. The big upside, however, is that they are actually talking about it. Out in the open. Big step, and I applaud them for that.

The other biggest buzz of the day was from Yahoo, in announcing the beta of their Fire Eagle service, an API for broadcasting your physical location to the web. I wouldn’t call it earth-shattering, but I think that there’s a good chance a number of cool things are built with it. Watch the video of it’s introduction, and then take a look here to quickly get an idea of the details. It would appear from the details that it was written in a highly usable way.

Of more direct importance to me, Google has announced their Contacts API. I despise when sites ask me to enter my username/password for other sites. The most offensive request is for Gmail. I don’t have any interesting emails, let me tell you… but I certainly don’t want to let others read them. The Contacts API is a safe way for distribution and use of your Gmail contacts, without threatening the security of your Gmail account or your other Google-stored information. With this, I should be able to sync my Gmail contacts with my desktop mail contacts. I’m very happy about that.

Heading up the long-since-overdue category, AOL has announced they’ve opened their Instant Messenger Protocol, OpenAIM. Finally. I remember ages ago when… well, it’s all in the past now. That’s one big wall that has been broken down between protocols, and hopefully Yahoo and Microsoft will fall in line. It will be great if other apps can finally use the features that have been limited to the AIM client for all this time. I use Adium and Pidgin most of the time (Adium, I believe uses Pidgin’s core), and look forward to seeing what they do with the new open protocol. (On a personal note, hopefully this doesn’t spell any negative news for my friends who work on AIM.)

The IE8 doctype meta waiting game

The first time I played Yahtzee was… only about a month ago. I won 3 of my first 4 games. It was a fun game. I wonder how that game would be if I played against… oh, let’s say… Microsoft. Probably… not so much.

Jeremy Keith, my favorite famous-web-developer-that-I-watch-from-afar-via-his-blog (sorry, didn’t have a better term for that… he seems like a fun guy) has written a follow up post about the IE8 doctype meta mess. As I’ve come to expect, he has eloquently suggested a rational and positive approach to the proposal. As I mentioned in my last post, the meta isn’t really that terrible, while the default behavior is. Jeremy, along with others, suggest we need to politely and intelligently urge Microsoft, hoping they re-consider. This of course, is the correct course of action. Insults, and things of that nature are just a waste… life’s too short.

The problem, is that life is short. The list of things that we’re waiting on from Microsoft is long. And there is very little crossed off! We’re still waiting on correct handling of CSS. We’re still waiting on correct javascript behavior. I worry that it will be forever before Microsoft takes it’s turn in this game.

I’m all for civil discourse. This IE8 hub-bub made me instantly think of an online petition. But while I will be cheering Microsoft on, excuse me if I keep my fingers crossed behind my back. Will Microsoft make the next move? Will they pause the game and get back to it? Hopefully. My father always told me that we had a relative who would pretend to sneeze while kicking the checker board. That wouldn’t be nice, but it would be swift. A game ended by neglect may be far more painful.