Why Streaming Video Makes You Wait

January 28, 2016

Have you ever wondered why this spinning icon Throbber shows up whenever you try to play an online video or skip forward in it? This video explains what’s happening and why:

 


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!


Explain/Teach Nearly Anything with this Hands-on Game

November 20, 2013

cloudBoard-TopAngle

cloudBoard is a new project on Kickstarter that intrigues me as it uses a physical board with puzzle-like pieces and a digital computer game component to teach various concepts, primarily to kids. I think this learning approach is ingenious, as it blends kids’ natural desire to play with (and relate to) something physical (like a classic board/puzzle game) and yet leverages the ability to drive video games, providing a rich visual element kids love. And not just kids. The guys at Digital Dream Labs have play-tested their invention with kids and adults alike, often finding that it bridges the generation gap, engaging young and old alike. Early play-testing also revealed some encouraging results with autistic individuals.

How’s it work? Players place various tiles in the cloudBoard in specific positions or sequences, and that becomes a direct link to functionality and features enabled in the video game. Repetitive play — the key to learning — is easy, accomplished by simply swapping or rearranging the pieces in the board, allowing learners to tinker with various configurations.

cloudBoard-TopDownWithStickers

3 things I love most about the cloudBoard project:

It bridges the physical and virtual. I’ve long been a believer in leveraging aspects of the physical world in explanation and teaching because people connect with physical things in a unique and memorable way. cloudBoard takes this to a whole new level, grabbing the best aspects of board and puzzle-piece games from our childhood while marrying them to what’s possible with modern digital computer technologies. And unlike the Skylanders concept, where the physical figure’s position or relationship to other figures is irrelevant, the physical cloudBoard pieces mean different things when they’re in different positions on the board.

cloudboard-cork

It’s not just a single game. Multiple games can be supported. While the Cork The Volcano game — designed to teach trial-and-error concepts, key to understanding computer programming — is the first game to be released, the Digital Dream Labs dudes have multiple other concepts in the works, including a chemisty game, a music game, and a farming game. Virtually any game can be created with the right software and new tops to the puzzle pieces. And here’s where the real extensibility of the cloudBoard concept shines…

Developers can extend it themselves.  I spoke with Justin Sabo from Digital Dream Labs, and I think this is a point worth emphasizing about their project. The game APIs will be open to those who wish program their own video game to interface with the cloudBoard hardware. And unlike some other game systems, cloudBoard is designed to run the same across many platforms (tablet, PC, etc.), extending its usefulness.

cloudBooard-piecesAlone

The tops of the puzzle pieces can also be swapped with other tops, allowing the physical aspect to be ever-changable but using the original pieces. (You don’t necessarily need brand new pieces for every game; just change the toppers.) Change the pictures? Fine. Add fuzzy three-dimensional toppers? Go for it. 3D-print your own? Why not? This is part of the future vision that Justin shared with me — that what they’ve created is a platform others can easily expand upon. Who knows how many educational games could be created.

Here’s what I don’t like about the cloudBoard project:

It’s not fully funded yet.  So spread the word and head on over to the cloudBoard kickstarter page to help make it a reality.


What is 64-bit?

October 1, 2013

Have you noticed that the technical specifications for computing technology always seem to be numbers that double after a while? This has particularly been true of numbers with the word “bit” after them. 8-bit. 16-bit. 32-bit. And now, yes, 64-bit is the latest buzz. But if you’re a normal person (not a computer person), what does this mean?

One of my colleagues (Ed) sent me a link to this short article that loosely explains what 64-bit means to you, the normal person: What the iPhone 5s ’64-bit’ processor means, in plain English. I particularly like the library and book analogy. While I see from the comments that the true technophiles object to the explanation, I’m still going to call it good enough for the normal person. By passing it along, I hope it’s helpful to you or someone you know.


Explaining Programming to Kids

September 14, 2013

There’s been a lot of focus on preparing the next generation to learn to code/program. (See Code.org for starters.) And many websites have sprung up sporting interactive tutorials for hands-on learning. But what about really young kids? Is it ever too early to learn the core concepts of programming?

Dan Shapiro doesn’t think so. He took a leave of absence from his job at Google to give the world another way: a board game. His project, Robot Turtles, went up on Kickstarter last week and is gaining funding. I hope he gets everything he needs, because this is a clever approach. Give kids a fun board game with great graphics, but at the heart of learning to route the Turtles appropriately, players learn the logic for writing basic computer programs. It’s brilliant.

So if you’ve got some kids you want to introduce to programming concepts in a fun, offline format, consider supporting the Robot Turtles project. It looks like it’s going to be a reality for now, but like Dan says, it may never be in print again.

Robot Turtles board game, courtesy Kickstarter project by Dan Shapiro


Computer People vs. Normal People

August 6, 2013

Have you noticed how there seem to be some people who just “get” computers and others who don’t? I call the former “computer people” while the latter are simply “normal.”

There’s nothing wrong with not being a computer person. In fact, I think the majority of the people in the world are not “computer people.” But here’s a true confession: I did not realize I actually was a computer person until much later in life. I thought I was like everyone else, until people started referring to me like I was “one of those people that understands computers.”

After pondering this for a great many years, I’ve finally acknowledged that I’m different, but more importantly, I understand the difference between normal people and computer people: “computer people” think like machines. They understand machines. They feel right at home with computers because computers are made by (and, except for a few exceptional attempts to the contrary which we’ll discuss shortly, for) people who enjoy controlling and operating machines.  I think this is why it’s difficult for these two camps to understand each other. One side is baffled that understanding technology is so difficult for the other; and the other thinks the first has been born with some innate magical ability.

I thought everyone would be able to learn to understand computers as easily as I did… until I began the journey of writing The Ultimate PC Primer. It was an attempt to make the mysterious approachable for the commoner and was eye-opening for me, forcing me to put myself in others’ positions to see what they don’t understand. Has anyone else thought this way, about bridging the gap? Actually, yes, and I think it worked well for him and for his customers.

Steve Jobs is arguably one of the most successful designers to find a way to bridge “normal people” with modern computing capabilities, and to do so wildly successfully in the public marketplace (not just in a research space). According to this article (Review: iOS 7 Gives Us Insight Into the Future of Mobility) he was a fan of skeuomorphic design. Skeuomorphism is when something mimics the materials or ornamental elements of something that exists in the real world (source).

I think this is partially why iOS and Apple’s mobile products experienced such a rapid adoption amongst “normal people,” even those without much understanding of prior personal computing technology. Mental associations with familiar things is both comforting and illustriative for “normal people,” something I’ve found “computer people” often don’t understand. They don’t need to because it comes easily, naturally. They understand machines just fine without any “artificial” metaphors. But for all the “normal people,” the mysterious black box is more usable when it feels like something from a past experience in real life. In  fact, there are some indications that connections to physical things are being craved more and more as our existence becomes increasingly virtual. Skeuomorphic design certainly plays off these desires nicely, but it can go overboard, as I (and others) have pointed out previously. Still, cleverly and subtly connecting a real world concept  — either audial or visual — to a digital interface  can be powerful and effective.

Since that iOS review article hints that skeuomorphic design is on its way out at Apple now, it will be interesting to see if the resulting design of computing devices once again starts to feel like it’s “by computer people, for computer people.”


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.


Copyright explained with puppets (by YouTube’s lawyers)

July 10, 2013

While Copyright law isn’t technology itself, if affects plenty of things dealing with technology. So I couldn’t help but re-post this clever video created by YouTube that explains copyright basics with….puppets!

Well done, YouTube!


APIs explained via a game show

November 12, 2012

Since I’m fond of analogies and metaphors for explanations, here’s the first thing I tell my learner to do when explaining to him/her what an API (Application Programming Interface) is. Watch the first half of this clip from the old game show Who Wants to be a Millionaire, where the contestant uses his “Phone a Friend” lifeline:

What’s “Phone a Friend?” When the contestant gets stuck, he/she can make a single phone call to any friend and ask the question at hand, hoping the friend’s response will be the correct answer (or help lead to the correct answer). Provided the call is made correctly, the question is asked correctly, and the friend is the right person to answer such a question, the response will greatly help the contestant/caller to do something he/she otherwise could not do alone. With that in mind….

What’s an API? It’s when computer code (or an entire program) makes a call to something else to do something it could not otherwise do alone, allowing it to be greater than it is by itself. The call must be made correctly, according to the rules the API specifies, so that the caller can ask correctly and the recipient can understand the request and respond appropriately. And unlike the game show contestants, computer programs aren’t limited to talking with just one API. Programmers/developers often leverage multiple existing APIs to accomplish greater holistic functionality rather than taking the time to develop all the desired functionality themselves. The chances are, most programs you use have been designed to tap some existing API to achieve some part of its functionality.

So, do computer programs do this a lot? You bet. Programs aren’t superheros*; they often just have a lot of friends to call.


* I’ll make an exception for Tron.