Grandma Warner's Molasses Cookies

My grandmother, Gladys Warner, was a formidable woman. She raised a family of six while working as a cook in a logging camp in the Adirondacks. When she made pies, she made them by the dozen. She nursed her sister's twins as well as one of her own. She hunted and fished. She grew most of her own food, canning lots of it even after getting huge freezer chests. She could knit a pair of mittens in an evening. And she made the best molasses cookies I have ever had.

This recipe makes 8-9 dozen, so make sure you have about 3 hours. Note that it doesn't use eggs, dairy products, or nuts, so it's a handy recipe if you have to worry about food allergies.

Ingredients

  • 1/2 cup brown sugar
  • 1 cup shortening
  • 1 cup molasses
  • 1 cup honey
  • 1 1/2 cup unsweetened applesauce
  • 1 tsp. salt
  • 2 heaping tsp. ginger
  • 2 heaping tsp. cinnamon
  • 2 heaping tsp. baking soda
  • 5-6 cups flour (about half a 5 lb. bag)
  • about 1/4 cup granulated sugar

Directions

  1. Preheat oven to 350F.
  2. Cream together the brown sugar and shortening.
  3. Add the molasses, honey, applesauce, salt, and spices and mix well.
  4. Mix the baking soda into about 4 cups of flour, and add to the mixture. Stir until smooth.
  5. Continue to add flour, mixing well, until the dough is very stiff. (The exact amount can vary based on humidity and who knows what else.)
  6. Drop large spoonfuls onto a greased cookie sheet. (Bigger than a walnut, but smaller than an apricot.)
  7. Butter the bottom of a glass and dip it in sugar. Use it to flatten the drops to between 1/3" and 1/2".
  8. Bake for 12-15 minutes, until they bounce back when tapped with a finger. If they brown, you've kept them in too long.
Dark, non-stick cookie sheets do not work well: the cookies tend to burn on the bottom. Ordinary greased metal sheets work fine; they won't stick at all if you let them cool on the cookie sheet for about 5 minutes before transferring them to cooling racks.

If stored in an air-tight container, these cookies are purported to last indefinitely without refrigeration. (But I've never been able to test this - they get eaten too fast!)


The myth of automated heading outlines

There's been a revived interest in automatically generated, logically nested headings maps. The HTML5 solution was to use the H1 element in each SECTION, and the browser would then figure out the correct level by the nesting of SECTION elements.  But browsers have not actually implemented this part of the specification, so this method does not work.

Heading outlines are particularly important for people using assistive technologies (see Background section below) so it would be a Good Thing if technology could help us improve their quality.

Further reading: The HTML5 Document Outline, by Steve Faulkner

Let's make a new element!

Jonathan Neal has put out a proposal to add a new element, H, to indicate the heading for a SECTION.  The idea is to provide a contextual heading for a given piece of content without having to know exactly what level it is in terms of the overall page. Browsers could then generate a logical outline based on nesting of SECTIONs.

This really leaves us where we are now: there is no value unless browsers actually implement it.

Further reading: The State of <H>, Jonathan Neal

What, actually, is the problem to be solved?

I have some bad news: heading and content hierarchies are based on the authors' intent and the what they are trying to communicate.  No algorithm can read a person's mind, so if you want your heading levels useful and meaningful, you have to do it yourself.  It doesn't really matter if you do it with numbered heading elements or by correct nesting, only you can know the relationships and hierarchies and make sure to use the markup that will best represent it.  If the author doesn't care about or understand content structure, nested SECTIONs will be abused just as badly as numbered headings.

The current debate seems to be stuck on how to generate an algorithm that can fix missing structure markup without breaking good structure markup.  I for one can imagine why browser vendors aren't interested in tackling this problem: you are guaranteed to make somebody angry with you.

Further reading: Do we need a new heading element? We don't know, by Jake Archibald

But what about content re-use?

The only real-life example of where code could help is content re-use.  In some publishing environments, you may have pieces of content that can be used in different places, and they may need different heading levels in those different places.  This is a legitimate issue, but in reality, it's not a very common one.

Content re-use is very appealing: there's only one place to keep information up-to-date while being able to pop it in everyplace it's useful.  We did a lot of work on enabling content re-use in Mass.Gov for these reasons. But it was almost never used: content often needed to be edited to make sense in the new context, and/or it was easier and better to just link to the existing content. When it was used, it created new content maintenance problems when the original was edited or deleted.  So, great idea, but not practical in most situations.

The wonders of content management systems

Where content re-use does make sense is in an environment with highly controlled information architecture and content curation, which requires a sophisticated content management system.  The obvious place to build automation for correct outlining is within that CMS, as part of the controls.  The page-generating code and templates control where different pieces of content go, so should also be able to control what heading levels are being used in those different places.

And that's pretty much what sites like this are doing already, so a browser-based algorithm is not going to solve any problems for them.

In less-rigid environments, with more content creators with greater latitude, you can still configure your CMS to make it easier for them to do the right thing. For instance, you can configure its WYSIWYG to not offer heading levels higher than authors should use.

Browsers are amazing, and are forgiving of so much bad markup, but it's not reasonable to expect them to fix everything.  When it comes to issues that have to with the actual meaning and purpose of content, it may not even be desirable to expect them to fix them.  Sometimes you just have to fix your own problems.

Background: Why headings are important

We use headings in written content to break up long chunks of text to make it easier to absorb.  A sighted user can easily scan the content to see what it is about and how it is organized.  Screen reader software gives users a list of headings and their levels that they can navigate from, or they can use keyboard commands to move from heading to heading, either sequentially or within a specific heading level.  There are browser extensions that give keyboard-only users similar methods.

If you have used heading levels correctly, it will be a logical outline of the content.  The most common errors are using only visual effects instead of heading markup, skipping levels, and incorrect nesting.

My history of voting and you should, too.

I went to high school in New York City, living with friends from my church.  I volunteered for the Mondale campaign, although too young to vote.  I was crushed when he lost. How could he lose when I cared so much and I had stuffed so many envelopes?!

I then moved to Boston for college. Meanwhile, my divorced parents had both moved.  I really had no idea where I lived, much less that I was able to vote in Boston. But I wasn't actually paying attention, disillusioned by politics and all.  So I didn't exercise my franchise for a number of years.

Then one day, Governor Dukakis was defeated by King and I realized that I was outraged, and felt guilty for not paying attention.

So I started paying attention and voting.  I have voted in every election since 1980, except one off-cycle local special election that slipped under my radar.

What I have learned over all those years is that local elections matter.  The person running for School Committee one year is running for mayor a few years later.  State Representatives run for Senate.  It's a pipeline, and if you want a President you feel like you can vote for whole-heartedly, you have to do your part to get the right people in all the lower level elections.

You also learn that people who run for office are people, and not a single one of them is perfect.  So you look to see if they share your values and priorities and how hard they work, and try to guess how much they may compromise themselves in order to get enough money to run again.  That any politicians are able to keep their souls intact is close to a miracle.  Expecting perfection is unreasonable.

The only way to change politics, and your choice of candidates, is to actually participate: research and vote, call and write them once they're elected, with questions, complaints, and thanks as warranted.  Let them know that you're out there and that you vote.  Otherwise, you are invisible and irrelevant.

The only vote that doesn't count is the one not cast.


Placeholder text: clever, or too clever?

HTML5 allows you to have "placeholder" text - text in a form field to give hints about what you should put there.  There are a number of ways to use it incorrectly and poorly.  It should never be used as the label for the field, because it disappears as soon as you click on it or tab into it.  "Wait, is this the zip code field?"  And it shouldn't be used for important instructions, for the same reason.  "What date format did they want me to use?"

For simple forms, like a search box or a user name and passwrod login screen, you can sometimes get away with it.  How confused could people get with a login screen?

Well, it seems you can even mess up a login screen, if you get a little too clever.

The login form below uses placeholder text instead of labels.  The "name or email" is pretty clear.  And the use of dots, just like the ones that obscure your password from prying eyes is, too.  Isn't that cute?

Screenshot of login form with placeholder text being used as labels:


You click on the user name field and type in your name.  A very high percentage of users then think, "Oh, look, it remembered my password!" and click on the "Sign in" button.

Screenshot of login form, where the text for the first field has disappeared after selection, but the cute dots remain:


Of course the login fails, and your help desk is swamped with people who can't figure out why their password doesn't work.

If you come up with a very clever use of the placeholder feature, be sure you have some actual users do some testing, the ones who are just there to sign in, not admire how clever you are.  It's not good design if your users can't figure out how to use it correctly.


Further information on placeholder text:

Survival tips for accessibility leads

I received a request for some advice from a newly named Accessibility Lead for a government agency.  He said, "I am being asked to provide accessibility guidance on products / software I have never used before; and, in my opinion, this is a rather dangerous venture."  I knew exactly what he meant.  You feel like you are being asked to wave the magic accessibility wand over any old tech that happens to come along, while knowing that there is no magic.

This is what I told him.  If you are in the same position, I hope this helps you, too.

There is no way anybody can be an expert in every aspect of how to implement something accessibly in every technology.  I’m sure not!  So here are some survival tips.

  • Never claim to “know it all” or let others burden you with that.
    • Admitting that you don’t know everything gives you a lot more credibility.
    • It also leaves room to work cooperatively – let the devs, authors, etc. (“creators”) in on the discovery process and they will be more committed and learn more.  This is much preferable to a “dump it over the wall to the accessibility guy” approach, where it makes it look like you are the problem when issues are found.

  • The general principals are the same: Perceivable, Operable, Understandable, and Robust.  And the guidelines under them in WCAG2 track nicely to just about any technology area.  The actual implementation and authoring techniques are where things vary.

  • Always look to the technology provider (software vendor, for instance) for implementation guidance.  Look for their white papers or developer guides that address accessible implementation/configuration. If it’s not on their website, the creators need to contact the provider to get it (or to let them know that it’s important.)
    • Your creators should have found and been using these before they come to you.  If they didn’t, send them back to find it, compare the guidance with what they have done, and make needed changes before they return.

  • There may not be tools like we have for web-based technologies (accessibility checkers, code inspection tools) so you may end up having to do testing just with AT: screen readers, magnifiers, and speech recognition.  It takes longer and you’re more likely (as a human) to miss things.
    • QA discipline is your friend here.  Identify a matrix of AT, platforms, and browsers (when applicable) that you need to test on to find source errors (versus AT bugs) and write formal test scripts.
    • Involve the creators in testing so they can learn how to do at least some of it themselves, and so they understand the actual problem.
    • Get Actual Users to do testing, too, as a reality check and to prioritize the severity of any issues found.



Stories

When Dave was a toddler, I would sometimes tell him stories at bedtime.  It was a good way to get him to settle down: no lights on, like you need for reading.

I don't remember many of those stories. There was a series about Bob (because he bobbed on the water) the (magic) golden sailboat and David and their ocean and harbor adventures. There was a whale with a deep slow voice and a hyperactive dolphin named Joy and a storm or two. About when the underwater city with its underwater inhabitants came around, the story sort of petered out.

One night, I couldn't come up with a story. No main character, no plot, no moral - I just drew a blank. But at that age, Dave was mad about trains, and it was winter. So I talked about the little trains and trolley cars that just went back and forth all through the storm, clearing the tracks inches at a time. And then about the train plows that come through after the storm, with their pointy noses sending up great wings of snow on either side, glinting and glowing in the sun, as they power down the long overland stretches of rail.

It was description, not story. It had a tiny lesson about getting things done by a big-bang approach, or by taking it little by little, but no judgment about which is better.  Did that even qualify as a "story"?  I didn't think so at the time; I rather thought I had wimped out that night.  But not Dave! To my surprise, he requested that story again and again, and remembers it still.

Hops in the Spring

Our hop plants loved the early warm weather we had. By mid-April, the first sprouts were already six to eight inches tall. They say you can eat them like asparagas, but such sacrilege would not be tolerated here.

Just a few weeks later, the first plants are already about three feet tall. We had set up the tripods last week, before the weekend's torrential rain. They doubled in size in that time! Plenty of other bines are appearing and doing their best to catch up to the earlier ones. As they grow, they reach for something to grow on. When they do, they start growing in a spiral aorund it. They don't have tendrils to hold on with, like vines do, but they do have hard nubs to give them a little traction.

They grow very quickly once they start climbing. They'll reach beyond the tripods by next week, so we're now rigging a trellis with rope, twine, a two-by-four and an old flag pole, and a hub cap. This has been used succesfully before. Really!

Once all the ropes are attached on the other side, to various bits of our house, we'll hoist the hub cap up the flag pole and pull it across, where the bits of twine tied to it and the ropes will dangle down in reach of the growing bines.

Sunday Morning Country with Sparrows

Every Sunday from 10 a.m. to 2 p.m., we listen to Sunday Morning Country on Boston College's radio station, WZBC (90.3FM, streaming at http://wzbc.org/listen.html) hosted by the incomparable Cousin Kate. That's what you're hearing in the background. The sparrows were very excited because we had just refilled the birdfeeder. It was mesmerizing to watch them swoop in and out, sometimes singly, sometimes en masse, seemingly in time to the music.

Early Fall In the West

Jon and I took a little jaunt to see the Rocky Mountains. We had a blast! When we came back, Jon wrote a narrative of our adventures, and then I added more pictures - selecting only the best of the thousands I took. The daily narratives are on Jon's blog and the pictures are on this blog, but here's a list of all the bits and pieces, for your convenience.