Shallow Thoughts

GetSET: Teaching Javascript to high school girls

Every summer I volunteer as an instructor for a one-day Javascript programming class at the GetSET summer technology camp for high school girls. GetSET is a great program run by the Society of Women Engineers. it's intended for minority girls from relatively poor neighborhoods, and the camp is free to the girls (thanks to some great corporate sponsors). They're selected through a competitive interview process so they're all amazingly smart and motivated, and it's always rewarding being involved.

Teaching programming in one day to people with no programming background at all is challenging, of course. You can't get into any of the details you'd like to cover, like style, or debugging techniques. By the time you get through if-else, for and while loops, some basic display methods, the usual debugging issues like reading error messages, and typographical issues like "Yes, uppercase and lowercase really are different" and "No, sorry, that's a colon, you need a semicolon", it's a pretty full day and the students are saturated.

I got drafted as lead presenter several years ago, by default by virtue of being the only one of the workshop leaders who actually programs in Javascript. For several years I'd been asking for a chance to rewrite the course to try to make it more fun and visual (originally it used a lot of form validation exercises), and starting with last year's class I finally got the chance. I built up a series of graphics and game exercises (using some of Sara Falamaki's Hangman code, which seemed perfect since she wrote it when she was about the same age as the girls in the class) and it went pretty well. Of course, we had no idea how fast the girls would go or how much material we could get through, so I tried to keep it flexible and we adjusted as needed.

Last year went pretty well, and in the time since then we've exchanged a lot of email about how we could improve it. We re-ordered some of the exercises, shifted our emphasis in a few places, factored some of the re-used code (like windowWidth()) into a library file so the exercise files weren't so long, and moved more of the visual examples earlier.

I also eliminated a lot of the slides. One of the biggest surprises last year was the "board work". I had one exercise where the user clicks in the page, and the student has to write the code to figure out whether the click was over the image or not. I had been nervous about that exercise -- I considered it the hardest of the exercises. You have to take the X and Y coordinates of the mouse click, the X and Y coordinates of the image (the upper left corner of the <div> or <img> tag), and the size of the image (assumed to be 200x200), and turn that all into a couple of lines of working Javascript code. Not hard once you understand the concepts, but hard to explain, right?

I hadn't made a slide for that, so we went to the whiteboard to draw out the image, the location of the mouse click, the location of the image's upper left corner, and figure out the math ... and the students, who had mostly been sitting passively through the heavily slide-intensive earlier stuff, came alive. They understood the diagram, they were able to fill in the blanks and keep track of mouse click X versus image X, and they didn't even have much trouble turning that into code they typed into their exercise. Fantastic!

Remembering that, I tried to use a lot fewer slides this year. I felt like I still needed to have slides to explain the basic concepts that they actually needed to use for the exercises -- but if there was anything I thought they could figure out from context, or anything that was just background, I cut it. I tried for as few slides as possible between exercises, and more places where we could elicit answers from the students. I think we still have too many slides and not enough "board work" -- but we're definitely making progress, and this year went a lot better and kept them much better engaged. We're considering next year doing the first several exercises on the board first, then letting them type it in to their own copies to verify that it works.

We did find we needed to leave code examples visible: after showing slides saying something like "Ex 7: Write a loop that writes a line of text in each color", I had to back up to the previous slide where I'd showed what the code actually looked like. I had planned on their using my "Javascript Quick Reference" handout for reference and not needing that information on the slides; but in fact, I think they were confused about the quickref and most never even opened it. Either that information needs to be in the handout, or it needs to be displayed on the screen as they work, or I have to direct them to the quickref page explicitly ("Now turn to page 3 in ...") or put that information in the exercises.

The graphical flower exercises were a big hit this year (I showed them early and promised we'd get to them, and when we did, just before lunch, several girls cheered) and, like last year, some of the girls who finished them earlier decided on their own that they wanted to change them to use other images, which was also a big hit. Several other girls decided they wanted more than 10 flowers displayed, and others hit on the idea of changing the timeout to be a lot shorter, which made for some very fun displays. Surprisingly, hardly anyone got into infinite loops and had to kill the browser (always a potential problem with javascript, especially when using popups like alert() or prompt()).

I still have some issues I haven't solved, like what to do about semicolons and braces. Javascript is fairly agnostic about them. Should I tell the girls that they're required? (I did that this year, but it's confusing because then when you get to "if" statements you have to explain why that's different.) Not mention them at all? (I'm leaning toward that for next year.)

And it's always a problem figuring out what the fastest girls should do while waiting for the rest to finish. This year, in addition to trying to make each exercise shorter, we tried having the girls work on them in groups of two or three, so they could help each other. It didn't quite work out that way -- they all worked on their own copies of the exercises but they did seem to collaborate more, and I think that's the best balance. We also encourage the ones who finish first to help the girls around them, which mostly they do on their own anyway.

And we really do need to find a better editor we can use on the Windows lab machines instead of Wordpad. Wordpad's font is too small on the projection machine, and on the lab machines it's impossible for most of us to tell the difference between parentheses, brackets and braces, which leads to lots of time-wasting subtle bugs. Surely there's something available for Windows that's easy to use, freely distributable, makes it easy to change the font, and has parenthesis and brace matching (syntax highlighting would be nice too). Well, we have a year to look for one now.

All in all, we had a good day and most of the girls gave the class high marks. Even the ones who concluded "I learned I shouldn't be a programmer because it takes too much attention to detail" said they liked the class. And we're fine with that -- not everybody wants to be a programmer, and the point isn't to force them into any specific track. We're happy if we can give them an idea of what computer programming is really like ... then they'll decide for themselves what they want to be.

Tags: education, javascript, programming, speaking
[ 11:54 Aug 09, 2008    More education | permalink to this entry ]

Review of Toastmasters manuals

With all the zillions of Toastmasters club web pages, very few people seem to write about them. A conversation in our club today about the advanced manuals made me realize that I'd never seen a review of the various Toastmasters advanced manuals -- which ones are useful, which ones are fun, which ones are poorly written or contain gotchas that makes it hard to complete their projects?

So I wrote one: a Review of Toastmasters manuals.

Tags: speaking, toastmasters
[ 20:16 Mar 06, 2008    More speaking | permalink to this entry ]

She's Geeky tech unconference

I just got back from She's Geeky. What a rush! It'll take me a while to wind down from this fabulous all-women meeting.

I have to admit, I was initially dubious. A conference for geeky women sounded great, but it struck me as kind of expensive -- $175 (with a $125 early-bird rate). That's very cheap as tech conferences go, but for a two-day "unconference", it was enough to turn off most local techie women I know: nearly all of them knew about She's Geeky and said "I'd love to go but I can't afford it." Full disclosure: I said the same thing, and wouldn't have gone myself had I not gotten a "scholarship", for which I am immensely grateful. (In retrospect, considering how well run it was, it probably would have been worth the early-bird price. But that's not easy to tell ahead of time.)

Monday consisted of lunch and informal discussion followed by two sessions of scheduled talks. I particularly liked the afternoon schedule, which included two different sessions of speaker training: the theory being that one factor holding women back in technology jobs is that we don't make ourselves visible by public speaking as much as we could. I went to the "Lightening (sic) Talks" session, headed by Danese Cooper. It didn't make me lighter, but we got some great advice at giving conference talks (lightning and otherwise) plus two rounds of practice at three minute talks. I'm not sure what I enjoyed more, the practice and useful feedback or the chance to listen to so many great short talks on disparate and interesting subjects.

Tuesday started way before normal geek time, with bagels and espresso and an explanation by conference organizer Kaliya Hamlin on how we'd use the Open Space process. Sessions would be an hour long, and we had eight rooms to work with, all charted on a huge grid on the wall. Anyone could run a session (or several). Write it (and your name) on a card, get up and tell the group about it, then find a time and space for it and tape it on the grid. Rules for sessions were few. For session leaders, Whoever comes to your session is the right audience, and whatever happens is what should have happened. For people attending a session there's the Rule of Two Feet: if you're not getting anything out of the session you're in, you should get up and get yourself to somewhere where you're contributing and/or learning. Not hard when there are seven other sessions to choose from.

This all worked exactly as described. Whatever hesitance many women may feel toward public speaking, there was no lack of volunteer session leaders on a wide variety of topics, both technical and social. I signed up to give a GIMP session before lunch; then in a morning session on server and firewall configuration given by fellow LinuxChix Gloria W. and Gaba, I noticed a few people having a lot of general Linux questions, in particular command-line questions, so I ran back to the wall grid and added an afternoon session on "Understanding the Linux command line".

Easily my favorite session of the conference was the Google Maps API talk by Pamela Fox of Google. I've been meaning to experiment with Google Maps and KML for a long time. I even have books on it sitting on my shelf. But I never seem to get over the hump: find a project and a specific task, then go RTFM and figure out how to write a KML file from scratch to do something fun and useful. Pamela got me over that in a hurry -- she showed us the "My Maps" tab in Google Maps (you have to be signed on to a Google account to use it). It includes tools for generating some starter KML interactively, and it even has a polygon editor, all implemented in AJAX (Javascript) and running in a browser. Wow! What a great way to get a running start on map mashups. There's also a whole open source Javascript API and set of libraries for writing creative web mapping apps. I'm sure I'll be experimenting with this a lot more and writing about it separately. Just this talk alone made the conference worthwhile, even without all the other great sessions.

But I didn't get a chance to experiment right away with any of that cool mapping stuff, because right after that session was one by speaker and comedian Heather Gold. Heather had given Saturday night's evening entertainment, and I am very sorry to have had to miss the show to go to a night class. The session was on self confidence, getting over fear of speaking, and connecting with the audience. Since the allotted space was noisy (the same one I'd ended up with for my GIMP talk, and the noise was definitely a problem), Heather led our small group out onto the balcony to enjoy the warm weather. The group was diverse and included women at very different levels of speaking, but Heather had great tips for all of us. She has great presence and a lot of useful things to say, and she's funny -- I'd love to see her on stage.

Everybody had a really positive attitude. At the Lightning Talks session on Saturday, Danese stressed "No whinging" as a general rule to follow (in talks or anywhere else), and I'd say the whole conference followed it. While we heard about lots of serious topics women face, I didn't hear any whining or "men are keeping us down" or that sort of negativism. There were some bad experiences shared as well as good ones, but the point was in finding solutions and making progress, not dwelling on problems. This was a group of women doing things.

There are only two changes I can think of that could have improved the conference at all. First, I already mentioned the cost. While it was fair considering the fantastic organization, great people, plus catered meals, it still lets out some of the women who could have benefitted the most: students and the un- and under-employed. A few of us LinuxChix talked about how much we'd love to see a similar conference held at a cheaper facility, without the handouts or the catered meals. Maybe some day we'll be able to make it happen.

Second (and this is a very minor point), it might have been helpful to have runners reminding people when sessions were ending, and perhaps making the sessions 55 minutes instead of an hour to encourage getting to the next session and starting on promptly.

Even without that, people mostly stuck to the schedule and Tuesday finished right on time: pretty amazing for a conference whose agenda had been made that morning with cardboard, tape and marking pens. I've seen unconferences before, and they're usually a disorganized mess. This one ran better than most scheduled conferences. Kaliya and her fellow organizers clearly know how to make this process work.

We all pitched in to clean up the room, and I braved the rush-hour freeway. And arrived home to find that my husband had cooked dinner and it was just about ready. What a nice ending to the day!

Tags: conference, tech, chix, speaking
[ 23:01 Oct 23, 2007    More misc | permalink to this entry ]

Logitech Cordless Presenter

I got a nifty new toy: a Logitech Cordless Presenter.

I've been watching some of the videos from LCA2007, and I like how some of the speakers made their presentations smoother, and avoided being tied to standing next to their computer, by using remote slide-changing gizmos. It wouldn't help for my GIMP presentations, since those are usually live demos, but I do give other types of talks.

I didn't find much on the web about remote presenters and Linux, and wasn't at all sure whether or how they worked. As usual with hardware, the only way to find out is to buy one and try it.

As it turns out, it works just fine, so I wrote up a review with details.

Tags: linux, speaking
[ 14:34 Feb 15, 2007    More linux | permalink to this entry ]

Firefox for Presentations: Hiding the URLbar

I've long been an advocate of making presentations in HTML rather than using more complex presentation software such as PowerPoint, Open Office Presenter, etc. For one thing, those presentation apps are rather heavyweight for my poor slow laptop. For another, you can put an HTML presentation on the web and everyone can see it right away, without needing to download the whole presentation and fire up extra software to see it.

The problem is that Mozilla's fullscreen mode doesn't give you an easy way to get rid of the URL/navigation bar, so your presentations look like you're showing web pages in a browser. That's fine for some audiences, but in some cases it looks a bit unpolished.

In the old Mozilla suite, I solved the problem by having a separate profile which I used only for presentations, in which I customized my browser to show no urlbar. But having separate profiles means you always have to specify one when you start up, and you can't quickly switch into presentation mode from a running browser. Surely there was a better way.

After some fruitless poking in the source, I decided to ask around on IRC, and Derek Pomery (nemo) came up with a wonderful CSS hack to do it. Just add one line to your chrome/userChrome.css file.

In Firefox:

#toolbar-menubar[moz-collapsed=true] + #nav-bar { display: none !important; }

In Seamonkey:

#main-menubar[moz-collapsed=true] + #nav-bar { display: none !important; }

This uses a nice CSS trick I hadn't seen before, adjacent sibling selectors, to set the visibility of one item based on the state of a sibling which appears earlier in the DOM tree.

(A tip for using the DOM Inspector to find out the names of items in fullscreen mode: since the menus are no longer visible, use Ctrl-Shift-I to bring up the DOM Inspector window. Then File->Inspect a Window and select the main content window, which gets you the chrome of the window, not just the content. Then you can explore the XUL hierarchy.)

This one-line CSS hack turns either Firefox or Seamonkey into an excellent presentation tool. If you haven't tried using HTML for presentations, I encourage you to try it. You may find that it has a lot of advantages over dedicated presentation software.

Addendum: I probably should have mentioned that View->Toolbars->Navigation Controls turns off the toolbar if you just need it for a one-time presentation or can't modify userChrome.css. You have to do it before you flip to fullscreen, of course, since the menus won't be there afterward, and then again when you flip back. I wasn't happy with this solution myself because of the two extra steps required every time, particularly because the steps are awkward since they require using the laptop's trackpad.

Tags: tech, web, firefox, speaking
[ 16:59 Apr 25, 2006    More tech/web | permalink to this entry ]