LMFAO parody to explain jQuery?

January 7, 2015

As a colleague and I were providing some introductory web development training, one of our pupils asked some questions about how web content works that isn’t static, changing state either by positional movement or by appearing/disappearing. The web pages in question used jQuery, and it was during our explanation of some basic jQuery concepts that I found myself saying something that sounded a little too much like LMFAO’s “Sexy and I Know It.”  Parodies of that song abound, so I thought, “Why not a parody to explain jQuery?” And this emerged shortly afterward: Read the rest of this entry »

Advertisements

Heartbleed explained with metaphors

April 13, 2014

Heartbleed. To most of us, it’s that mysterious annoyance that has caused us to change passwords for many of our on-line accounts. But can Heartbleed be explained in a way it’s not seen as a fatal hole in the “magic” of the Internet?

While many sites have explained Heartbleed’s literal failures through code and even comic, I felt an explanation with some everyday analogies and metaphors was still lacking…. until I stumbled across Eric Limer’s article on Heartbleed over at Gizmodo. Not only has Eric saved me the time of crafting an explanation, he’s done an admirable job of making the magic of computer code and internet communication simple through his real-world examples.

First, Eric explains how Heartbleed derives it’s name — from “heartbeat,” a standard operation that two computers must use to make sure they’re talking to each other in sync. Since a personal computer and an Web server are disconnected until they have a reason to talk to each other (over the Internet), they must have some way to check to make sure they both stay connected to each other during their conversation. Like calling your bank via telephone, you don’t want to have your phone call disconnected until your business transaction is finished. This “heartbeat” operation is a way to ensure nothing has gone wrong at either end during the computers’ conversation. Eric uses a clever reference to old audio cassette tapes to illustrate this:

It’s like making sure that both spindles in a cassette tape are moving when you’re playing it. If one spindle stops and the other keeps going, something will break.

Heartbleed was named as such because the recently uncovered flaw is in this “heartbeat” operation, or more specifically, the coded instructions for the “heartbeat” procedure that the Web server follows. As I’ve explained in my book, computers don’t have common sense. They follow only the instructions provided (in the form of code), literally. Like a robot/zombie chef, they follow the recipe exactly as written. So the problem of Heartbleed is actually one of an oversight in the written recipe for the “heartbeat” function. And while a human might be able to recognize this type of sloppy instruction in a recipe and compensate, computers cannot.

So what’s the problem? Read the rest of this entry »


Reflections on my relationship with Flash

February 14, 2014

Someone recently asked me why I liked Flash so much and have been a loyal advocate for so long. Even though HTML5 and modern browsers have allegedly (according to web design enthusiasts) rung the death knell for Flash, my affection for Flash lives on. But why? Well, I had to do some soul-searching to answer that, and my answer may surprise you with it’s simplicity that (perhaps rightly, perhaps blindly, depending on your perspective) ignores nearly all the technical pros/cons, tell-tale marketplace warnings, and standards-based arguments in the Flash vs. HTML5 debate. But hear me out….

I loved Flash because the products I created with it… just… worked. By “worked,” I mean my creations, designed once by me, were experienced by all end users how I meant for the experience to be “played back.”  Flash worked because the creation software and player/plugin were all offered and controlled by the same company. By having everything from creation to playback owned under one roof, you can expect it ought to have worked flawlessly. And nearly all of the time, it did. It’s not to say creating and deploying Flash-based projects was always easy or as clear to achieve as it could have been. But, from my designer’s point of view, once I validated that my creation worked, I could be confident it would work almost universally, for everyone. I could depend on it — rely on it to be close enough to “fact” that I didn’t have to worry about my creation being presented as anything other than intended to the end user. There’s something that feels “right” about that — something inside that says, “Yeah, it shouldn’t have to be any harder than this.”

Contrast that to the web browsers of Macromedia Flash’s hayday, all from different vendors, all with different features, all with incompatibilities, standardization largely lacking. As I’m fond of saying, no one won the browser war, but the consumers definitely lost. (And in some ways, perhaps us designers did, too.) Faced with those browsers — a “playback” mechanism that I could never be guaranteed would present a creation consistently or faithfully — it’s still not hard for me to look back and validate my affection for Flash. Imagine being a major motion picture studio, releasing a film to theaters around the world, and never knowing if each moviegoer in each theater will have the same experience. Imagine an experience where, in some theaters’ presentation of your film, an actor mysteriously (or perhaps magically) simply doesn’t show up in a scene or two of the completed film. That’s what trying to create rich web experiences felt like during the browser wars without Flash. And while HTML5 standards seem to be heading the right direction now, it still feels that way to a certain extent. It feels like creating a single experience shouldn’t be as hard as it still is.

I understand all the pros/cons of standards, innovation, monopolies, software life-cycles, etc. My mind knows all that. But I can’t help feeling that those of us who love designing digital experiences for others to consume continue to spend more time on technical nuances of the presentation/playback product (out of unfortunate necessity) than on the part of the craft we enjoy. It’s that part of me that loves Flash. In a relatively easy-to-understand interface, it allowed creators to produce relatively rich experiences for the masses to consume, without the mess of sifting the browser vendors’ junk. So Flash or no Flash, I hope those days I remember so fondly will return in the future — for the good of all of us who love creation of the experience more than the gritty technical details.


UPDATE: Three days after posting this, Lars Doucet shared some similar feelings on Flash development in his post: Flash is dead; long live OpenFL!


The DOM as a… dinosaur?

July 17, 2013

dino-skeleton

When I was last at UC Berkeley, I found this dinosaur skeleton in a science building and tried to capture it in one photo. As you can see, it’s a large model and I had to splice two pictures together. In person, it’s even more impressive. And it got me wondering: who had the job of assembling this huge thing and how did they go about it?

I pictured all the bones arriving in boxes or crates. And I sure hope a good instruction manual came with them. I imagined that manual (like most assembly manuals) would probably identify the pieces with some kind of anatomical naming convention, or at the very least, by number. And the assemblers would interpret those diagrams and instructions, fetching each piece from the create one by one, placing it in position.

So how does this relate to web design and how web pages and browsers work?

I’ve often been called upon to explain the DOM (Document Object Model) that is the basis of web pages, and I always point back to my Berkeley dinosaur friend for a great analogy because it can be used to explain the DOM, HTML, CSS, and (to a lesser extent) why jQuery is lauded for its simplicity.

The HTML document is the assembly manual, and the DOM is the resulting model. The web browser reads the HTML to understand the structure it needs to create. It forms a sort of memory-picture or “mental model.” Then it fetches the pieces required one by one (from the web server) and assembles the actual web page (that you experience) based on that model. This model is the DOM, and it is a living model that can be changed once initially assembled. If you change the DOM, the web page also changes to reflect the new model. It’s kind of like the bones with skin over the top. While the DOM is behind the scenes, it’s providing the structure for everything you actually see and experience. Change the bones, and the skin/body itself will reflectively change to the person experiencing it on the outside.

But is structure all the DOM deals with? Not quite.

Let’s return to the dinosaur model again. Once assembled, if you wanted to paint just one bone, to treat it differently from the others, you’d need to know how to identify it for the painting crew.  It would be important, for efficient painting and styling, if the painters understood the identification convention used for dinosaur bones. You’d give the painter the number or anatomical name for the bone you wished to tint and then specify the color.

For web pages, this is the job of Cascading Style Sheets. CSS provides this way of identifying and selecting elements in the model to which you want to apply a visual style or effect. Selector syntax is crucial for identifying the parts of the DOM to which styles should be applied, which will treat the appearance of each targeted element in the web page as specified. This is why mastering CSS rules and selector syntax is a major part of web design.

And finally, if, like in A Night at the Museum, you wanted to make your dinosaur skeleton dance around the room, you’d need a way to select specific bones and describe how to move them in a pre-planned way. That’s the beauty and simplicity of why people like jQuery. It uses the same CSS selector syntax for selecting elements, to target them for specific actions instead of visual styles.

Modern web browsers do all this interpretation, assembly, and styling every time you load a web page, and they do it relatively quickly given how many structural, style, and action details are contained in the average page. But the reality is that the browser, like the dinosaur assembly crew, is simply following the assembly manual instructions. Ever tried to cook something from a bad recipe? Carelessly written instructions will produce unreliable results, which is why web development is a profession. Because even through the browser is interpreting the HTML and applying the CSS, make no bones about it, it’s still the people behind the scenes writing the script and puling the strings.

I hope you enjoyed this explanation and remember it the next time you admire any model, be it prehistoric or modern.


Why it’s important to think outside the check box

April 28, 2011

Once again, I recently found myself in a consulting meeting, needing to explain the difference between check boxes and radio buttons. Those that follow my blog might ask, “Ben, why do you gripe about this so much?” So let me clarify why it’s important to think through this issue.

My issue is NOT about

1. expecting others to be able to describe computer technology correctly. (After all, the functionality of check boxes and radio buttons is retroactively obvious. Once you see the function of both explained side by side, it’s readily apparent what the differences are and why.) It has never been my desire to turn the general population into computer engineers, developers, or designers.

It’s only partially about

2. others being able to design appropriately — describing the appropriate interface element for the application — though this is crucially important. I have increasingly seen check boxes and radio buttons used interchangeably and the functionality behind them intentionally coded incorrectly, resulting in a radio button interface behaving like a set of check boxes and check boxes being leveraged like radio buttons. In fact, just a handful of weeks ago I was auditing some on-line training from a standard provider for that particular industry. All the exams were multiple-choice questions. The questions did not indicate if one response or multiple responses were required. Check boxes were used, yet most often, only one response was correct. But not always. Perhaps this was an intentional design choice. But having also just consulted with individuals designing a new website (who clearly did not know the difference and selected the wrong interface element), I can’t guarantee the choice was an informed one. In this case, had I not thought through the interface, applied my technology background, and then assessed the questions again, I might have failed the exam.

Foremost, my quandary is Read the rest of this entry »


Technology Mindedness Test

March 18, 2010

Immersed in technology consulting over the last year, I have encountered a number of situations in which my clients have demonstrated an awareness that increased technology knowledge (on their part) might be beneficial. In short, they realize they don’t think like “technology-minded people,” and they want to know how. While their intentions are good, their questions are misguided. Questions like, “What should I read,” “what should I study…” and even “who should I hire?”

These questions reveal a deeper issue: someone not technology-minded often won’t know what technology mindedness looks like. “Technology acuity” is perceived as something that can be acquired through “old school” means if one simply had a list of the “correct” means. While I certainly don’t discount the value of multiple methods of learning, trying to “learn technology” like a historical subject — without understanding the nature of technology itself — is folly. “Technology” is  (sorry to use a negative concept) like the cold virus. There isn’t just one. It can’t be memorized. The best in the field seek not to carve its traits in stone, but to understand its nature. The world we live in expects technology-knowledge to be increasing every day, so trying to “fake it” is self-defeating in the long-run. There’s a disparity in the two models of learning and understanding that can’t be reconciled.

I tried to think of a way to illustrate this for my clients, and I came up with a simple comparison test: two questions, asked of a set of technology-savvy individuals I know and then asked also of my clients. When compared, the differences in answers should stand out. Here’s the test: Read the rest of this entry »


A mouse? Bring me my Tab! — Using concept correlation to teach new users

November 19, 2008

I had a fascinating experience while at the “cell phone store” some time ago. I was changing providers/networks and phones, but what was most interesting was the Web-based system the “clerks” used to enter my information and how they interacted with it. You see, the “clerks” were comprised of a middle-aged manager and a teenage assistant. Now before you get ahead of me, recognize that this posting isn’t necessarily about their age difference or the Software Generation Gap. This manager did know how to use the computer and the Web-based system. What I found intriguing was that the manger used the mouse to click from one text entry field to the next, which worked just fine. He was getting the job done. However, his teenage subordinate stared over his shoulder the entire transaction, periodically peppering him with flippant “suggestions” like, “Don’t use the mouse. Just push the Tab key. It’s faster.” (Note for those who don’t know: like a frog hopping from one lily pad to the next, pushing the Tab key on the keyboard will cause the focus or cursor to jump to the next text/input field on the screen).

Having learned many of my computer skills from colleagues and my original computer mentor, I began debating with myself about how computer skills are really learned. Are they most often learned by direct instruction, passive observation/demonstration, or by concept correlation? In this particular example, I asked myself the following, “How did the teenager learn and subsequently know that the Tab key worked in the Web browser?”

I came up with a few plausible answers: Read the rest of this entry »