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 »
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!
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.
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 »