Unstoppable Robot Ninja

The site navigation:

This Is the Journal.

There are currently 807 entries in Unstoppable Robot Ninja.

Here are the most recent five.

The Last Five Entries:

See All

  1. Platformed.

    Jeremy said something yesterday that’s been rattling around in my head since he posted it:

    The web isn’t a “platform” like a native OS: it’s a continuum. Varying support levels work with progressive enhancement.

    As he usually does, Jeremy put words to something that’s been bugging me for some time.

    As I see it: we play the long game in this business. Standards get authored, browsers implement them (often at a varied, staggered pace), and, over time, we learn to rely on them in our work.

    Despite that, we keep getting hung-up on perceived short-term failings in various browsers. No, IE6 doesn’t have document.querySelectorAll support; no, we don’t have wide in-browser access to a user’s camera; no, there isn’t a way to reliably detect touch; no, we don’t have reliable insight into the user’s “context.”

    Often, that leads to people deciding the web is being “held back.” So there’s some hopscotching of, say, progressive enhancement—which, in addition to being a great philosophy, has been shown to have real, practical benefits to businesses—in favor of “not being held back.” So, in response, we make the same arguments—good and great arguments, mind, but we’ve been making them for some time now.

    I don’t really have any answers here—hell, I’m not entirely sure what I’m griping about. But I do wonder if our collective short-term frustrations leads us to longer-term losses. And seeing the web not as a “platform” but as a “continuum”—a truly fluid, chaotic design medium serving millions of imperfect clients—might help.

    I mean, ages ago John Allsopp wrote about “[embracing] the ebb and flow of things” on the web. But it’s taken me some fourteen years to realize he wasn’t just talking about layout: our attitude toward the web has to be as flexible as our designs. And maybe it’s worth remembering that the web’ll get there, eventually—we just need to keep playing that long game.


    My thanks to Scott Jehl, Jeff Lembeck, and Mat Marquis, who reviewed an earlier draft in Editorially.

    This is a blog entry posted on day 13413 in the Journal.

    Comments disabled.

  2. So you’re interested in a responsive design workshop…

    Hey so I’m a little excited about this: Karen McGrane and I are launching a responsive design workshop.

    In the past few years, in speaking with client companies and colleagues, the one thing that comes is that responsive web design doesn’t begin and end with CSS. The best responsive sites are founded upon a culture of performance; they’re made with iterative design and development practices; they plan for accessibility and progressive enhancement from the outset; and they are, perhaps most importantly, built upon a well-researched and -executed content strategy.

    In other words, successfully designing responsively isn’t just about fluid grids and media queries: it’s about designing a better process. And that’s the challenge Karen and I find really, really interesting. (And as it happens, we have a bunch of ideas on the topic, too.)

    To that end, we’ve designed a workshop to share the many things we’ve learned about responsive design and mobile content strategy over the course of one day or two. And we want to share them with you and your company.

    If all this sounds interesting to you, we happen to have a little website with a bit more detail. Check it out; we’d love to hear what you think.

    This is a blog entry posted on day 13369 in the Journal.

    Comments disabled.

  3. Speaking? Pack a plan.

    It seems to be the season for presentation tips. First, Mark had a handy hit-list of tips for speakers and audience members. Then, Andy shared a few easy tips for prettying up one’s default slide designs. And then, Rands noted a test slide for your deck isn’t the worst idea. (In fact, I goddamn love it; Tim Brown’s already made a Keynote-ready template available.)

    If you can’t guess, I fucking love this.

    See, I’m not formally trained in web design or public speaking—and in both arenas, the best education I’ve gotten is watching really talented people work. My presentation style’s changed considerably over the years, as the likes of Kristina Halvorson, Karen McGrane, Jeff Veen, Doug Bowman, Erin Kissane, and Dan Cederholm have been hugely influential on my own style. I’d watch them work, and try to figure out what I liked about their style, and why I liked it. And then I’d try to be better the next time I was onstage. And heck, when people write about how they work, well—that’s just damned grand.

    All that said, I don’t have any significant tips to add to the above, but thought I’d list two things I find especially helpful. One’s semi-philosophical; the other, less so.

    1. Eliminate dependencies in your work. I try to ensure my presentations aren’t reliant on audio or a network connection. Basically, depending on where you’re speaking, it’s entirely possible either—or both!—of those things won’t be available to you. So this usually means that if I want to show the audience how a certain page might work, I’ll record a little screencast, rather than assuming I can jump out of Keynote into the browser. (I use the idiosyncratic-as-hell ScreenFlow, but any ol’ app will do.)

      In other words: by all means, use audio in your presentation, or incorporate online demos! But if you do, make sure you’re planning for failure, and have a contingency plan at the ready. (I guess you could see this as a corollary to progressive enhancement, but in Keynote form.)

    2. Pack a bag. Related to this, I have a small satchel inside my laptop bag. In it, there is:

      • One VGA adapter for my MacBook Air.
      • One USB presentation remote. (There are many such remotes available. You want this one.)
      • Fresh backup batteries for that remote.
      • A USB ethernet adapter for my MacBook Air.

      In other words, this is the stuff my computer needs to actually run the presentation I’ve prepared.

      Now, most conference organizers will have many of these things, but I don’t want to expect that they will. They’re busy folks, after all. In other words, I want to ensure I’m the only one responsible for the quality of my presentation, and packing a small bag of critical cords and adapters helps me do that.

      (As a bonus, I’ve started traveling with a short (6") VGA cable, rolled up and tucked into a large, rarely-used pocket of my laptop bag. This has been supremely handy for doing run-throughs on hotel room TVs the night before a talk.)

    This is a blog entry posted on day 13311 in the Journal.

    Comments disabled.

  4. “The second step is inclusiveness.”

    A friend just sent this quote my way; it’s from Ben Schneiderman’s Leonardo’s Laptop, which I will be buying immediately:

    The second step toward the new computing is inclusiveness, what I call Universal Usability, enabling all citizens to succeed in using information and communication technologies to support their tasks. This goal leads to designs that support users with new or old computers, fast or slow network connections, and small or large screens. It should make possible participation not only by young and old, novice and expert, able and disabled, but also those yearning for literacy, overcoming insecurities, and coping with various limitations. Responding to these digital divide challenges will take hard work, but we have come to learn that diversity promotes quality. Accommodating diversity pushes designers to produce higher quality for all users.

    Emphasis mine because, well, damn.

    This is a blog entry posted on day 13305 in the Journal.

    Comments disabled.

  5. Keynote, Magic Move, and You

    A confession: I love working in Keynote. Love it.

    (I’m speaking, of course, of Keynote ’09. Not the feature-stripped version that was released last month. Still, I’m hopeful it’ll improve over time, since it is so very pretty.)

    It’s not perfect, mind you—after four or five years of use, the program’s got some not-insignificant stability issues, crashing way more often than I’d like. But after all that time it’s still one of my favorite visual editors: it’s great for quickly prototyping UI components, sketching out ideas for animation timing, and, yes, making slides.

    Anyway: over the years, folks have said some very kind things about the visual design of my presentations. I don’t have any special knowledge about Keynote, mind, but thought I’d share a couple things I use in my presentations, in case anyone else finds them helpful.

    First up: Magic Move.


    Basically, Magic Move is a transition you can apply between two slides. If the second slide shares any objects—images, text boxes, or what-have-you—with the first slide, those objects will be, well, magically moved from one position to the next.

    Here’s a very, very simple example:

    As you can see, there’s just one object on both slides: a picture of my good friend Dwayne. The image is the same on both slides—you can duplicate the slide, or copy/paste the object to the second slide—but since its position changed, Magic Move kinda tweens the photo to its new position.

    Now, I don’t use Magic Move a lot, usually preferring to just lean on simple dissolves between slides. But it’s great for managing more complex animations, like this one:

    This animation requires a bit more setup, but the principle is basically the same:

    1. In the first slide, the “screenshots” you see are basically a lot of tiny little screencaps, each containing just one element of the interface. (So there’s an image for the toolbar in Editorially’s editor, another for the discussion panel, another for the account menu avatar, and so on.)
      1. When I’m arranging complex flyouts like this, I’ll usually have a reference screenshot on the canvas as a base layer, and place the smaller screencaps atop it. Just to make sure everything’s aligned, that is.
    2. Then, in the second slide, I move all those small images where I’d like them to end up.
    3. Turn on Magic Move, and you’re left with a neat little flyout cross-section of an interface.

    As with most things Keynote-related, Magic Move is pretty reliable…but the more you use it, you’ll probably run up against a couple idiosyncrasies. You can’t magicmove (oh god i’m so sorry) an object if it has any builds or actions on it; animated objects (YES MOM, I’M TALKING ABOUT GIFs) will just blink to their new position; and some objects might move completely counter to what you’d expect.

    And as with anything animation-driven, it’s very, very easy to overuse and abuse: try to consider marrying the animation with what you’re actually saying, and ensure the visuals don’t outwhelm your words as you’re presenting. That said, Magic Move is a fantastic tool to keep near at hand—when used just right I think it can be, well, kinda magical.

    This is a blog entry posted on day 13302 in the Journal.

    Comments disabled.

This was Ethan Marcotte’s Unstoppable Robot Ninja.

You are welcome.

Design and content © 2014 Ethan Marcotte. All rights reserved.

Photo copyright © LucasFilm.

Skip to the navigation, or skip to main content.