The Birth of Fluent Learning: the More Things Change…
Read Fluent Entity Framework and more than 24,000 other books and videos on Safari Books Online. Start a free trial today.
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Visit our Women in Technology Resource Center.
Rebecca Riordan is the author of the "Fluent" series, which includes Fluent Entity Framework, Fluent Visual Basic and Fluent C#.
Thirty years ago, I was an undergraduate studying the History of Art at Johns Hopkins University, and computers were big scary things that lived in the basement of the Engineering building, tended by a coterie of awkward young men with slide rules and pocket protectors. They were probably still being built with vacuum tubes. (The computers, not the young men.) But I didn’t know anything about that stuff then. I was one of the cool artsy kids, and back then cool artsy kids didn’t speak to people with slide rules and pocket protectors.
It was the world before the Internet. If you wanted to know something, you found a book or a journal and looked it up. If you were researching a subject, you started with the readers’ guides to periodical literature. For those of you who aren’t familiar with readers’ guides, they were indices of all the articles published in magazines and journals in a specific field during a specific period of time. (Think of them as a kind of prehistoric Google.) In the field of art history, there were four or five different readers’ guides, and each guide consisted of one volume for each year, going back over 100 years.
Yep, that’s four or five hundred volumes. An entire room full of books. And yep, you had to check each one individually. Every one of the many, many papers I wrote at university started with a couple of days sitting on the floor of the special collections room surrounded by readers’ guides. I’d take down a few volumes, check each one for a dozen different related subjects, and then put them back. Rinse and repeat. Sometimes I’d find something relevant; most of the time I didn’t, but I always had to check them all.Every. Single. Volume. One at a time.
I remember the moment so clearly. It was the beginning of my senior year, and I was doing the preliminary research on what would become my senior thesis. I was sitting on the floor, surrounded by readers’ guides, and I thought to myself, “There has just GOT to be a better way.”
I complained aboutthe tedium of preliminary research to my brother. Luckily for me, my brother had a shiny new degree in Computer Science from Cal Poly. (He also had a slide rule and a pocket protector, but we can’t pick our family.) That was the first time I ever heard the word “database”. We talked about a world in which all those separate sources of information could be combined, and you’d only have to ask your question once.
It sounded great. It sounded wonderful. It also sounded like science fiction. But three months after I graduated, IBM released the first PC and the world changed forever.
Flash forward to 2010. The reality of making a living in the real world had forced me out of art history and into this new field we called “information technology,” partly because it was interesting to me, but mostly because that’s where the jobs were. (When was the last time you saw a want ad for an art historian?) In the last thirty years, I’d climbed the corporate ladder of a major software company, built and sold two consultancies, and made a small name for myself writing computer tutorials.
Now I was working on a project that required me to learn JavaScript. I’m not a stupid woman, and I know my way around a computer. Like anyone who has been working in this industry long enough, I’ve learned a dozen programming languages and platforms in the course of my career. But I was really struggling with how scoping works in JavaScript. (I’m still not sure I really understand Javascript closures.)
I remember the moment so clearly. I was sitting in my office—on a chair this time—with three JavaScript books open on my desk and a dozen Web pages open in my browser, and I thought to myself, “There has just GOT to be a better way.”
Not having a sibling with a convenient degree in teaching, I went to the library. (That hasn’t changed either: If I want to know something, and I’m not sure exactly where to look, I still try to find a book or journal and look it up.) I found a wonderful book by Donna E. Walker Tileston, What Every Teacher Should Know about Effective Teaching Strategies (Corwin, 2003), and the Fluent Learning series was born.
I spent the next few months researching cognitive science and instructional design. It turns out that the people who teach professionally know quite a lot about the best way to do it. It also turns out that those of us who write computer tutorials have been doing almost everything wrong. In our industry you need to be learning all the time just to stay even. Studying new languages, technologies and methodologies is just a fact of life. But we were making all that learning a lot harder than it needs to be. I was determined to find a way to fix that.
It isn’t really our fault. I’m quite sure that nobody ever set out to write a book that made a subject hard to understand, any more than anybody ever set out to design software that was hard to use. But both of these things happen all the time, because nobody gets to know everything. (More’s the pity.) Egregiously difficult interfaces get built because programmers are too busy coding to learn UX or graphic design. Egregiously difficult tutorials get written because authors are too busy learning JavaScript or relational database design or…whatever…to learn instructional design. (Assuming they even know such a thing exists. I didn’t, until I found that book.)
And that was one of the big issues that worried me when I was designing the series: We can’t expect authors to take the time to study instructional design, any more than we can expect programmers to take the time to study art or the patterns of human interaction. This is the 21st century. Everybody I know already has more work than one person can reasonably do in a lifetime. But in a lovely, lucky bit of symmetry, I found the answer in my subject.
It’s a fundamental principle of both cognitive science and instructional design that people learn by making mental models, and that they make those models primarily by analogy. We compare and contrast the “new stuff” with “old stuff” that we already know in order to understand and remember it.
Well, in this industry, we know about patterns. Whether it’s a design pattern, an algorithm, or just the syntax of some programming statement, we work with patterns on a daily basis. And that’s what Fluent Learning is. It’s a pattern, or more properly a set of patterns, for presenting information in a way that makes it as easy as possible for people to learn. The patterns are based on my research but (at least in theory) you don’t need to understand the principles in order to use the patterns.
From simple things like how to write the chapter task list, to more complicated ones like how to build exercises based on Bloom’s hierarchy of task complexity, Fluent Learning is ultimately just a set of patterns. The patterning starts with the structure of the book as a whole. Fluent Learning books begin with an overview chapter that links the subject of the book to something the reader is likely to already know (a cognitive principle called “attaching”) and end with a final summary chapter that walks the reader through the entire subject (analogous to something teachers call a “knowledge organizer”).
Each chapter in between uses this basic pattern in miniature, and adds some patterns for presenting detail: priming (the old “tell them what you’re going to tell them” principle), exploring (exercises over exposition), and elaborating (returning to a subject several times to provide more detail, rather than trying to present everything there is to know about it all at once). All of these are fundamental to the learning process.
In my research, I learned some ways of categorizing the information to be taught, and the techniques teachers have developed for teaching each type. Those are folded into the Fluent patterns, too, as is Bloom’s hierarchy, so that exercises stay interesting. (And so that they’re real exercises, not just sample code presented one step at a time.) There are more, but I’m sure you get the idea.
Of course in birthing the series, there were lots of other things that had to happen. There were templates to build and graphics to design. (The two years I spent studying studio art before I moved to art history left me a failed artist, but they sure come in handy now.) But when all is said and done, Fluent Learning is just a set of patterns that anybody should be able to learn and apply. No degree in cognitive science or teaching credentials required.
But notice that I said “should be able to learn and apply.” I’ve just finished up my fourth title in the series. I’ve tweaked the graphics and adjusted the process with each title, and I think each title is a little better for it. It’s only now that I feel reasonably confident that I can make these patterns accessible to the experts who write computer tutorials.
But I still have a lot to work to do systemizing and documenting the patterns and structures before they’re really accessible. As it stands, the book templates still require too much understanding of the underlying principles.
For more articles and resources, visit our Women in Technology page.